You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2008/04/01 01:05:01 UTC
Re: Dynamic configuration for the hackathon?
Issac Goldstand wrote:
>
> Paul Querna wrote:
>> Akins, Brian wrote:
>>> On 3/26/08 9:06 AM, "Nick Kew" <ni...@webthing.com> wrote:
>>>
>>>> There seems to be a demand for dynamic per-request configuration,
>>>> as evidenced by the number of users hacking it with mod_rewrite,
>>>> and the other very limited tools available. Modern mod_rewrite
>>>> usage commonly looks like programming, but it's not designed as
>>>> a programming language. Result: confused and frustrated users.
>>>
>>>
>>> This is what I had in mind when I suggested having <Lua> blocks of
>>> code. No
>>> need to invent a new language when a perfectly fine one exists...
>>>
>>
>> +1, and embed Lua in the core, and a dozen problems just like this are
>> solved.
>
> -0.5 PLEASE not in the core. Make mod_wombat a standard module and
> part of the default moduleset, whatever, but let's not make more core
> dependencies, please?!?
-0.99 - agreed. Perl is perfectly happy having <perl> blocks as modular
behaviors... I've noticed a trend in the last few years of building on the
core (and folks rightfully accused me of growing mod_proxy core when new
directives are rightfully part of mod_proxy_{whatever}).
Let's focus on keeping it in useful pieces, even if they are built by
default.
Re: Dynamic configuration for the hackathon?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 1, 2008, at 9:40 AM, Torsten Foertsch wrote:
> On Tue 01 Apr 2008, Jim Jagielski wrote:
>> On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote:
>>> You cannot add virtual servers on the fly
>>
>> Hmmm.... let's see now. If we have a default Vhost that all non-
>> matched
>> name-based hosts get directed to configured, then a mod_perl based
>> handler can be adjusted to look at the Server header and do
>> "different
>> stuff" based on what it's set to... envision a simple dynamic
>> mapping.
>
> I know one can do that. But a VHost has a server_rec, maybe a separate
> error_log and access_log, etc. Those cannot be created at request
> time. That
> is what I meant.
>
Gotcha.
Re: Dynamic configuration for the hackathon?
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/1/08 11:21 AM, "Torsten Foertsch" <to...@gmx.net> wrote:
> On Tue 01 Apr 2008, Akins, Brian wrote:
>> In pseudo config, like niq is suggesting, you could have something like:
>>
>> <If HTTP_HEADER{Host} =~ cnn\.com$ || TCPPort == 8080>
>> #cnn specific stuff here...
>> DocumentRoot /htdocs/cnn
>> CutomLog "|/usr/bin/logger cnn" my_format
>> ErrorLog /var/log/cnn.error
>> </If>
>
> I don't like that. I think there are security considerations why logfiles are
> opened from the parent process as root. But with other logging mechanisms
> that provide write-only semantics it is good. In my setup the apache logs to
> a named pipe to a process outside the chroot.
The example wasn't about logs, it was just an example of how, if you wanted,
could do virtual hosts using niq's if/else style. Nothing says that the
logs wouldn't be opened in parent by root. If log config was per dir (which
we "emulate" with env variables) this would "just work."
> As I understood it the main problem with the current mod_rewrite based config
> is that it is too complex. The new language has to watch out not to end at
> the same place. One thing that I think is messy is the use of subprocess_env
> to pass information from module to module and even from administrator to
> module: no-gzip, force-gzip, downgrade-1.0, nokeepalive, redirect-carefully
> etc.
+1 to all that...
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Dynamic configuration for the hackathon?
Posted by Torsten Foertsch <to...@gmx.net>.
On Tue 01 Apr 2008, Akins, Brian wrote:
> In pseudo config, like niq is suggesting, you could have something like:
>
> <If HTTP_HEADER{Host} =~ cnn\.com$ || TCPPort == 8080>
> #cnn specific stuff here...
> DocumentRoot /htdocs/cnn
> CutomLog "|/usr/bin/logger cnn" my_format
> ErrorLog /var/log/cnn.error
> </If>
I don't like that. I think there are security considerations why logfiles are
opened from the parent process as root. But with other logging mechanisms
that provide write-only semantics it is good. In my setup the apache logs to
a named pipe to a process outside the chroot.
To really create vhosts on the fly I think a new hook in the MPM would be good
that is called from a configuration provider module. It reconfigures the
parent apache and does a graceful restart. This way almost anything can be
reconfigured. A question is whether the provider should send changes to the
apache or a complete new config. In the former case we'd need something like
UnListen localhost:80
CloseErrorLog ...
DeleteVirtualHost localhost:80
In the end the server_rec would go away. We have one server with a list of
loaded modules, a PidFile and an AcceptMutex that is listening on a list of
ports. The rest is configurable this way:
<if localport==443 and localaddr=1.2.3.4>
SSLCertificateFile ...
Protocol http # expecting HTTP to be spoken on the wire
<if header_in{Host}=~cnn\.com>
Timeout 10
ErrorLog ...
</if>
</if>
Or rather the request is passed to the config module that checks localport and
localaddr and issues the SSLCertificateFile directive. Then it checks the
Host-header ...
As for dynamic request configuration, I'd wish some configuration provider
with intelligent conftree caching. That provider then implements a language
as it likes, LUA, Perl, Apache-style <if>...</if>, ... It generates a list of
directives that is compiled into a conftree.
As I understood it the main problem with the current mod_rewrite based config
is that it is too complex. The new language has to watch out not to end at
the same place. One thing that I think is messy is the use of subprocess_env
to pass information from module to module and even from administrator to
module: no-gzip, force-gzip, downgrade-1.0, nokeepalive, redirect-carefully
etc.
Torsten
Re: Dynamic configuration for the hackathon?
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/1/08 9:40 AM, "Torsten Foertsch" <to...@gmx.net> wrote:
> I know one can do that. But a VHost has a server_rec, maybe a separate
> error_log and access_log, etc. Those cannot be created at request time. That
> is what I meant.
Well....
I was hacking around with the idea that the selection of vhost is a hook,
rather than how it is now. Basically, what I did was protect the vhost list
with a mutex, so you can add/delete (well not fully delete) vhosts. Combine
that with a "global" logger (ie, piped logger to syslog-ng) and the access
and error logs are "created" on the fly as well.
In the end, it was way too hacky and I haven't thought about it much in well
over a year.
In pseudo config, like niq is suggesting, you could have something like:
<If HTTP_HEADER{Host} =~ cnn\.com$ || TCPPort == 8080>
#cnn specific stuff here...
DocumentRoot /htdocs/cnn
CutomLog "|/usr/bin/logger cnn" my_format
ErrorLog /var/log/cnn.error
</If>
Hmmmm....
Would just have to move a bunch of stuff to per_dir and make sure all of our
directory config creation and merging is very fast...
This IF/else stuff could be done in a module and not in core for testing
purposes. Not quite where I'd like the config to be, but this may actually
be obtainable in near future.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Dynamic configuration for the hackathon?
Posted by Torsten Foertsch <to...@gmx.net>.
On Tue 01 Apr 2008, Jim Jagielski wrote:
> On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote:
> > You cannot add virtual servers on the fly
>
> Hmmm.... let's see now. If we have a default Vhost that all non-matched
> name-based hosts get directed to configured, then a mod_perl based
> handler can be adjusted to look at the Server header and do "different
> stuff" based on what it's set to... envision a simple dynamic
> mapping.
I know one can do that. But a VHost has a server_rec, maybe a separate
error_log and access_log, etc. Those cannot be created at request time. That
is what I meant.
Torsten
Re: Dynamic configuration for the hackathon?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote:
>
> You cannot add virtual servers on the fly
Hmmm.... let's see now. If we have a default Vhost that all non-matched
name-based hosts get directed to configured, then a mod_perl based
handler can be adjusted to look at the Server header and do "different
stuff" based on what it's set to... envision a simple dynamic
mapping.
Re: Configuration Issues to Address [was Re: Dynamic configuration
for the hackathon?]
Posted by Nick Kew <ni...@webthing.com>.
On Thu, 03 Apr 2008 11:22:00 -0400
"Akins, Brian" <Br...@turner.com> wrote:
> <If HTTP_HEADER{'Host'} == www.cnn.com and Port == 8080>
> DocumentRoot /www/cnn
> ServerAdmin someone@domain.com
> etc....
That basically comes out of what I committed this morning.
Well, up to a point: it only applies to the per-dir config.
> Maybe no need for Directory, location, etc, either...
>
I'm thinking more of displacing tortuous mod_rewrite-based
configs than any of the old containers (except possibly
the much-misunderstood-and-abused <Limit>).
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/3/2008 at 8:06 AM, in message
<BA...@jaguNET.com>, Jim Jagielski
<ji...@jaguNET.com> wrote:
> Another good topic of discussion:
>
> Time for a 2.4 release? I wouldn't mind pushing that along
> and get some of the feature-set of 2.4 out before we do too
> much ripping with the inevitable delays associated with that :)
Please let's get 2.4 out. It would be great to finally have the new Authz configuration logic see the light of day along with other functionality that has been sitting around for a while.
Brad
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
>
> <Limit> is of course a crusty old relative.
Limit is unrelated, it's fundamentally borked (directive must know
it is participating in a limit-ed section, cannot overly multiple
limit-ed sections because that directive has never created a conf
section, and there is no exception thrown when a non-participating
directive is nested within a limit).
This is why I'm not 'fixing' <Limit ... there are simply too many
broken configs out there.
Bill
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by Nick Kew <ni...@webthing.com>.
On Thu, 03 Apr 2008 11:25:56 -0400
"Akins, Brian" <Br...@turner.com> wrote:
> On 4/3/08 10:47 AM, "William A. Rowe, Jr." <wr...@rowe-clan.net>
> wrote:
>
> > I'll commit the <Method >
>
> <If HTTP_Method == GET>
> ...
> </If>
May work already (not tested) if Rewrite is active
(so method is available as an env var). Certainly
on the radar.
<Limit> is of course a crusty old relative.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: AuthzMergeRules directive
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/4/2008 at 5:43 PM, in message <47...@remulak.net>, "Paul J.
Reder" <re...@remulak.net> wrote:
> Perhaps it would make more sense to provide this as an explicit value rather
> than
> On vs. Off and set the default to the previous behavior. Perhaps something
> like:
>
> AuthzMergeRules [AND | OR | OVERRIDE] with default being OVERRIDE (if I grok
> correctly)
>
> Meaning that any directives specified at only one level would be merged to
> lower
> levels, but the merge behavior of directives specified at multiple levels
> would
> be controlled by this directive (i.e. ANDed, ORed, or OVERRIDEn with levels
> above
> it). This could result in complex logic if subsequent levels of containers
> mixed
> AND, OR, and OVERRIDE, but if it was designed to be explicit then the user
> would
> have specific control over each authbit along the way.
>
When I originally looked at the implementation of the authzMergeRules directive, the above suggestion was my first thought. However I think I decided not to go this route simply because the same thing could be accomplished in a less complex way by making the user explicitly decide the merging rules within the configuration of the directory block itself. In other words, if they wanted OR merging between a higher level and a lower level block, then do nothing or specify <SatisfyOne> in the lower level block. If they wanted AND merging then specify <SatisfyAll> in the lower level block. This follows the same concepts as would be done within a single directory block. This avoids having to resolve logic conflicts and precedents between two different directives, AuthzMergeRules and <SatisfyXXX>
Brad
Re: AuthzMergeRules directive
Posted by "Paul J. Reder" <re...@remulak.net>.
Perhaps it would make more sense to provide this as an explicit value rather than
On vs. Off and set the default to the previous behavior. Perhaps something like:
AuthzMergeRules [AND | OR | OVERRIDE] with default being OVERRIDE (if I grok correctly)
Meaning that any directives specified at only one level would be merged to lower
levels, but the merge behavior of directives specified at multiple levels would
be controlled by this directive (i.e. ANDed, ORed, or OVERRIDEn with levels above
it). This could result in complex logic if subsequent levels of containers mixed
AND, OR, and OVERRIDE, but if it was designed to be explicit then the user would
have specific control over each authbit along the way.
Paul J. Reder
Brad Nicholes wrote:
>>>> On 4/4/2008 at 11:37 AM, in message <47...@pearsoncmg.com>, Chris
> Darroch <ch...@pearsoncmg.com> wrote:
>> William A. Rowe, Jr. wrote:
>>
>>>> I've been working with the 2.4 authn/z stuff a bit lately and
>>>> what I keep tripping over is that the default authorization merge rule
>>>> uses OR logic. For example, if I enable mod_access_compat and
>>>> put in a traditional:
>>> I wonder if anyone would offer a fastfeather talk next week on wed or
>>> thurs - it's only 15 minutes - to introduce what's upcoming in 2.4?
>> I won't be there, but here's a recap of the issue for discussion.
>> (Caveat: I may be missing something important!)
>>
>> With 2.2 and prior versions, one can do something like:
>>
>> <Directory /htdocs>
>> Require valid-user
>> </Directory>
>> <Directory /htdocs/admin>
>> Require user admin
>> </Directory>
>>
>> The logic which is then applied is:
>>
>> 1) For all requests under /htdocs, except those under /htdocs/admin,
>> require any valid user.
>> 2) For all requests under /htdocs/admin, require the "admin" user.
>>
>> With 2.4, unless I'm missing something, the same configuration
>> produces the logic:
>>
>> 1) For all requests under /htdocs, except those under /htdocs/admin,
>> require any valid user.
>> 2) For all requests under /htdocs/admin, require any valid user OR
>> require the user "admin". Of course this grants any valid user access.
>>
>> To get the old behaviour, you seem to need to add
>> "AuthzMergeRules Off" to the second <Directory>. I just tested
>> versions of this configuration with 2.2 and 2.4 and I think I'm
>> describing the situation correctly. Assuming I am, I fear this
>> will surprise a lot of people who think they've secured their
>> systems after upgrading. It certainly caught me short.
>>
>> Perhaps the default AuthzMergeRules setting should be Off rather
>> than On, at least when merging across configuration blocks?
>>
>
> So here was the thinking behind it when AuthzMergeRules was introduced. Maybe there is still a bug here that needs to be addressed.
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44C4E0FA.8060205@apache.org%3e
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44CA3C33.6720.00AC.0@novell.com%3e
>
> Brad
>
>
>
>
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: AuthzMergeRules directive
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Apr 16, 2008 at 9:31 PM, Brad Nicholes <BN...@novell.com> wrote:
> I could go along with switching the default merging rule from OR to AND, even within a dir block. The reason why it is OR today was basically for backward compatibility. Since there really wasn't any kind of logic before, OR was just the default. If we switch to AND as being the default within a dir block, it may break some existing configurations. However I also think that AND is a safer merging rule going forward.
+1. AND makes more sense as the default - if they want OR, they can
use a directive... -- justin
Re: AuthzMergeRules directive
Posted by Ruediger Pluem <rp...@apache.org>.
On 09.04.2008 19:08, Chris Darroch wrote:
> Chris Darroch wrote:
> Writing that all out it mostly just seems like a depressingly
> large amount of work, but otherwise feels like it might offer a
> way forward, both for people upgrading from 2.2 and those starting
> fresh with 2.4. Thoughts?
From a first and quick look seems good.
Regards
Rüdiger
How to measure throughput
Posted by Niko Wilfritz Sianipar Sianipar <ni...@yahoo.co.id>.
I want to add a number code in sendfile_it_all function in core_filters.s. The web server will send the file according to the connection's throughput. I use SO_PRIORITY and setsockopt (differentiared service mechanism) to do that. the problem is how to measure the connection's throughput before the sendfile_it_all send the file requested for that connection. Assumption here is one connection only request for one file and uses one socket. Any suggestion??
Best,
Niko Wilfritz Sianipar
Teknik Informatika IT Telkom Bandung
---------------------------------
Bergabunglah dengan orang-orang yang berwawasan, di bidang Anda di Yahoo! Answers
Re: AuthzMergeRules directive
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Brad Nicholes wrote:
> I finally got around to making the switch so that the default merge
> rule is AND rather than OR. However after making the switch, it
> occurred to me that since the default rule is AND now, the
> AuthzMergeRules default should remain ON. Otherwise the rule
> inheritance won't happen by default which would leave authentication
> holes in sub-directories. I think with the default being changed
> to AND, authz should be behaving as discussed on this thread.
Thanks, much appreciated. I'll try to set up some tests and
take a look as soon as I can.
It's been a while since I thought about this stuff, but I think
the reason I was keen to make the AuthzMergeRules default off was that
it more closely emulated the pre-2.4 behaviour, so that people wouldn't
be surprised to discover their 2.2 configurations weren't working
as expected. Combined with a default OR rule that might have led, I
thought, to unanticipated security holes -- users given access to a
subdir with it's own authz config because the OR with the parent dir
short- circuited the subdir's authz. Using AND as the default rule will
at a minimum close off that problem.
My hunch (absent any testing; sorry!) is that a default AND will
mean such subdirs are sometimes just not available after an upgrade to 2.4
(assuming no authz config changes are made by someone who doesn't read
the release notes) because users won't have access to both the parent dir
and the subdir. In 2.2, they'd be authorized against just the subdir's
config; here, they'll need to pass the parent's too. (I think.) Anyway,
I'll try to work in some testing in the next week or two.
Regardless, this change closes a big security problem for
quick-and-dirty upgraders, I believe. Thanks again,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: AuthzMergeRules directive
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 5/2/2008 at 11:54 AM, in message <48...@pearsoncmg.com>, Chris
Darroch <ch...@pearsoncmg.com> wrote:
> Brad Nicholes wrote:
>
>> So what I am really trying to say is that intra-block logic and
>> inter-block logic as far as merging goes, are tied together. If we
>> want to change the way that the logic of two block is merged, we
>> would also have to change the base state of each independent block.
>> It's all or nothing. This would affect how the following block is
>> evaluated:
>>
>> <Directory /foo>
>> require user joe
>> require user sue
>> </Directory>
>>
>> As it currently stands, the logic when combining these two rules would
>> be OR. If we make the change, this would also change the same
>> configuration to use AND instead. I think we determined that this
>> logic would be more secure anyway even if it is different than 2.2.x.
>
> Well, I suppose the absolutely key thing is to set the default
> AuthzMergeRules state to "Off". Next up, I guess try changing the
> "On" merge state to AND and we'll do some thinking and testing at
> that point.
>
> It does look to me like the pre-2.4 intra-block logic was OR,
> but I don't know how widely people would have depended on that
> (as in your example above). My gut instinct is that we'll wind up
> having to replicate OR within blocks, but implement AND between
> blocks, to achieve both backwards-compatibility and good security.
>
> As a first step, though, I'd suggest just making the two changes
> to the existing defaults (AuthzMergeRules Off as default, and On => AND)
> and we'll review again at that point.
>
I finally got around to making the switch so that the default merge rule is AND rather than OR. However after making the switch, it occurred to me that since the default rule is AND now, the AuthzMergeRules default should remain ON. Otherwise the rule inheritance won't happen by default which would leave authentication holes in sub-directories. I think with the default being changed to AND, authz should be behaving as discussed on this thread.
Brad
Re: AuthzMergeRules directive
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Brad Nicholes wrote:
> So what I am really trying to say is that intra-block logic and
> inter-block logic as far as merging goes, are tied together. If we
> want to change the way that the logic of two block is merged, we
> would also have to change the base state of each independent block.
> It's all or nothing. This would affect how the following block is
> evaluated:
>
> <Directory /foo>
> require user joe
> require user sue
> </Directory>
>
> As it currently stands, the logic when combining these two rules would
> be OR. If we make the change, this would also change the same
> configuration to use AND instead. I think we determined that this
> logic would be more secure anyway even if it is different than 2.2.x.
Well, I suppose the absolutely key thing is to set the default
AuthzMergeRules state to "Off". Next up, I guess try changing the
"On" merge state to AND and we'll do some thinking and testing at
that point.
It does look to me like the pre-2.4 intra-block logic was OR,
but I don't know how widely people would have depended on that
(as in your example above). My gut instinct is that we'll wind up
having to replicate OR within blocks, but implement AND between
blocks, to achieve both backwards-compatibility and good security.
As a first step, though, I'd suggest just making the two changes
to the existing defaults (AuthzMergeRules Off as default, and On => AND)
and we'll review again at that point.
For my part I hope to deal with a parallel, unrelated, and hopefully
uncontroversial set of authn/z edits once SVN returns, namely changing all
the hard-coded "0" provider versions to use AUTHN/Z_PROVIDER_VERSION macros.
That's a simple first step toward the work outlined in this thread:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200804.mbox/%3c47FEC643.3080602@pearsoncmg.com%3e
Thanks again,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: AuthzMergeRules directive
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/18/2008 at 8:53 AM, in message <48...@pearsoncmg.com>, Chris
Darroch <ch...@pearsoncmg.com> wrote:
> Brad Nicholes wrote:
>
>> I could go along with switching the default merging rule from OR to AND,
>> even within a dir block. The reason why it is OR today was basically
>> for backward compatibility. Since there really wasn't any kind of logic
>> before, OR was just the default. If we switch to AND as being the default
>> within a dir block, it may break some existing configurations.
>> However I also think that AND is a safer merging rule going forward.
>
> If we just switch the AuthzMergeRules default state to Off, and make
> On mean AND, that would be a great start. Then maybe we can revisit
> and take a look at what breaks if the within-block merging is AND too;
> if it breaks too much stuff, maybe it needs to stay OR. Right now
> I can't say I have an informed opinion on that. Thanks again for working
> through this stuff,
>
> Chris.
After re-examining the code, the above suggestion is much easier said than done. The reason why is because base <Directory> logic starts from the AUTHZ_REQSTATE_ONE (OR) state. So if you have two <Directory> blocks, their respective per-dir structures are storing their authz logic as it was evaluated during configuration time. Then when the two <Directory> blocks are merged, they are merged according to current state. In other words, the following <Directory> block would be merged using OR:
<Directory /foo>
require user joe
</Directory>
<Directory /foo/bar>
authzmergerules on
require user sue
</Directory>
The reason why is because when the <Directory> blocks were first evaluated independently, the starting state was AUTHZ_REQSTATE_ONE. However in the following example the two <Directory> block will be merge with AND:
<Directory /foo>
require user joe
</Directory>
<Directory /foo/bar>
authzmergerules on
<satisfyall>
require user sue
</satisfyall>
</Directory>
The reason why AND is used in this situation is because the <satisfyall> block in the subdirectory changed its starting state from AUTHZ_REQSTATE_ONE (OR) to AUTHZ_REQSTATE_ALL (AND). There isn't any way to insert a different merging operator. It is always the sub-directory that determines how it will be merged into its parent.
So what I am really trying to say is that intra-block logic and inter-block logic as far as merging goes, are tied together. If we want to change the way that the logic of two block is merged, we would also have to change the base state of each independent block. It's all or nothing. This would affect how the following block is evaluated:
<Directory /foo>
require user joe
require user sue
</Directory>
As it currently stands, the logic when combining these two rules would be OR. If we make the change, this would also change the same configuration to use AND instead. I think we determined that this logic would be more secure anyway even if it is different than 2.2.x.
thoughts?
Brad
Re: AuthzMergeRules directive
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Brad Nicholes wrote:
> I could go along with switching the default merging rule from OR to AND,
> even within a dir block. The reason why it is OR today was basically
> for backward compatibility. Since there really wasn't any kind of logic
> before, OR was just the default. If we switch to AND as being the default
> within a dir block, it may break some existing configurations.
> However I also think that AND is a safer merging rule going forward.
If we just switch the AuthzMergeRules default state to Off, and make
On mean AND, that would be a great start. Then maybe we can revisit
and take a look at what breaks if the within-block merging is AND too;
if it breaks too much stuff, maybe it needs to stay OR. Right now
I can't say I have an informed opinion on that. Thanks again for working
through this stuff,
Chris.
Re: AuthzMergeRules directive
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/14/2008 at 3:29 PM, in message <48...@pearsoncmg.com>, Chris
Darroch <ch...@pearsoncmg.com> wrote:
> Brad Nicholes wrote:
>
>> This is where it starts to go wrong for me. Where it gets confusing
>> for somebody who is trying to figure out what the configuration
>> is doing is:
>>
>> <Directory /www/pages>
>> <SatisfyAll>
>> Require ip 10.10.0.1
>> Require ldap-group sales
>> <SatisfyOne>
>> Require ldap-group ne-sales
>> Require ldap-group sw-sales
>> </SatisfyOne>
>> </SatisfyAll>
>> </Directory>
>>
>> <Directory /www/pages/private>
>> AuthzMergeRules SatisfyOne
>> <SatisfyAll>
>> Require ldap-group marketing
>> Require ldap-group alt-marketing
>> </SatisfyAll>
>> </Directory>
>>
>> Now I have to reconcile the logic of the parent with the logic of
>> both the AuthzMergeRules and the <SatisfyAll> tag. Even though it
>> might not always look like the cleanest configuration, I think it
>> will be less confusing if the logic rules were confined to
>> the <SatisfyAll> and <SatisfyOne> tags rather than introducing
>> alternate logic directives.
>
[snip]
> If you'd like to stick to just "Off" (my proposed default for
> AuthzMergeRules) and "On", perhaps AND should be the logic implemented
> by "On"? Consider the following, where AND'ing helps tighten
> security as you go down the tree:
>
[snip]
> Personally, I'm gradually coming around to the feeling that AND is
> more useful/secure than OR when merging per-dir blocks, and possibly
> even within a single per-dir block (although that's another conversation),
> and so should either be an option to AuthzMergeRules or the action
> implemented by "On" if there are only two states.
>
> The reason I say it might make sense to AND authz requirements
> within a block is that it "reads" a little more naturally. Consider
> the following, which suggests to me that I need a shirt and shoes
> to be served, not one or the other:
>
> <Directory /www/service>
> Require shirt on
> Require shoes on
> </Directory>
>
> At rate rate, thanks for hashing through all my scattershot ideas
> on this stuff.
>
I could go along with switching the default merging rule from OR to AND, even within a dir block. The reason why it is OR today was basically for backward compatibility. Since there really wasn't any kind of logic before, OR was just the default. If we switch to AND as being the default within a dir block, it may break some existing configurations. However I also think that AND is a safer merging rule going forward.
Brad
Re: AuthzMergeRules directive
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Brad Nicholes wrote:
> This is where it starts to go wrong for me. Where it gets confusing
> for somebody who is trying to figure out what the configuration
> is doing is:
>
> <Directory /www/pages>
> <SatisfyAll>
> Require ip 10.10.0.1
> Require ldap-group sales
> <SatisfyOne>
> Require ldap-group ne-sales
> Require ldap-group sw-sales
> </SatisfyOne>
> </SatisfyAll>
> </Directory>
>
> <Directory /www/pages/private>
> AuthzMergeRules SatisfyOne
> <SatisfyAll>
> Require ldap-group marketing
> Require ldap-group alt-marketing
> </SatisfyAll>
> </Directory>
>
> Now I have to reconcile the logic of the parent with the logic of
> both the AuthzMergeRules and the <SatisfyAll> tag. Even though it
> might not always look like the cleanest configuration, I think it
> will be less confusing if the logic rules were confined to
> the <SatisfyAll> and <SatisfyOne> tags rather than introducing
> alternate logic directives.
I take your point about complexity, but on the other hand,
these aren't alternate logic directives -- they're additional.
The logic specified above for /www/pages/private would be:
( Require ip 10.10.0.1
&&
Require ldap-group sales
&&
( Require ldap-group ne-sales
||
Require ldap-group sw-sales))
|| <- AuthzMergeRules SastifyOne
( Require ldap-group marketing
&&
Require ldap-group alt-marketing)
> At least with AuthzMergeRules being ON or OFF, the only thing I need
> to know is if I am merging with the parent or not. All of the
> logic rules just flow from there.
Granted, the above example is complex and maybe non-intuitive,
but most people aren't going to attempt or need such a large set
of authz directives. For those who really do, there are surely
going to be cases where AND'ing block is useful while OR'ing is
not at all (since OR'ing tends to short-circuit the configurations
deeper down the document tree, which seems unlikely to be what people
will mostly want).
If you'd like to stick to just "Off" (my proposed default for
AuthzMergeRules) and "On", perhaps AND should be the logic implemented
by "On"? Consider the following, where AND'ing helps tighten
security as you go down the tree:
<Directory /www/private>
Require ip 10.10.0.1
</Directory>
<Directory /www/private/sales>
## must come from 10.10.0.1
AuthzMergeRules SatisfyAll
<SatisfyAll>
Require ldap-group sales
<SatisfyOne>
Require ldap-group ne-sales
Require ldap-group sw-sales
</SatisfyOne>
</SatisfyAll>
</Directory>
<Directory /www/private/sales/admin>
## must come from 10.10.0.1, belong to "sales", and also
## belong to one of "ne-sales" or "sw-sales"
AuthzMergeRules SatisfyAll
<SatisfyAll>
Require ldap-group admin
Require ldap-group sales-admin
</SatisfyAll>
</Directory>
Perhaps others have opinions on this stuff? Basically my principal
concern is that the default AuthzMergeRules setting must be "Off".
Beyond that, I can live any other choices.
Personally, I'm gradually coming around to the feeling that AND is
more useful/secure than OR when merging per-dir blocks, and possibly
even within a single per-dir block (although that's another conversation),
and so should either be an option to AuthzMergeRules or the action
implemented by "On" if there are only two states.
The reason I say it might make sense to AND authz requirements
within a block is that it "reads" a little more naturally. Consider
the following, which suggests to me that I need a shirt and shoes
to be served, not one or the other:
<Directory /www/service>
Require shirt on
Require shoes on
</Directory>
At rate rate, thanks for hashing through all my scattershot ideas
on this stuff.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: AuthzMergeRules directive
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/14/2008 at 12:21 PM, in message <48...@pearsoncmg.com>, Chris
Darroch <ch...@pearsoncmg.com> wrote:
> Brad Nicholes wrote:
>
>> I'm not real excited about adding a new authz directive. Authn and
>> authz are already very complex and adding a new directive to the mix will
>> just help to confuse people even more.
>
> That's a good point. Mostly the idea of an Accept replacement for
> Require came up as a way to distinguish pre-2.4 and 2.4 per-dir authz,
> and in case there were any "Require foo" directives which had slightly
> different meanings in the two contexts and which might therefore trip
> people up. If we can do without it, all the better.
>
>
>> I am OK with this one except for the reason that I mentioned before.
>> By allowing authz to be inherited even when AuthzMergeRules is OFF is
>> kind of a conflict. In other words, since AuthzMergeRules OFF implies
>> an AND, 1 AND 0 should be 0 or no authz rather than inherited authz.
>> However I could buy into this if it seems to make more intuitive sense
>> to the user.
>
> Well, I may be missing something, but what I envisioned was that
> AuthzMergeRules had three options: "Off" (i.e., inherited until overridden,
> the pre-2.4 default), "SatisfyOne", and "SatisfyAll". That would give
> administrators full control over how they wanted authz in different
> per-dir blocks to be merged.
>
> It seems to me we have three basic possibilities when it comes to
> merging authz across per-dir blocks, and the most common authz case
> to consider is going to be where security gets tighter as you move down
> the document tree. Imagine something like the following in a pre-2.4
> configuration, where "admin" is not a member of "team":
>
> <Directory /htdocs>
> ## full access
> </Directory>
> <Directory /htdocs/team>
> ## anyone in "team" has access
> Require group team
> </Directory>
> <Directory /htdocs/team/admin>
> ## only "admin" user has access
> Require user admin
> </Directory>
>
>
> 1) The first option for 2.4 merging is to use OR logic (the current
> default in trunk). This leads to anyone in "team" having access to
> /htdocs/team/admin, I believe. I think I'd have to vote -1 against
> this, because it will lead to lots of previously secure configurations
> becoming insecure. Plus it would seem to increase the required
> number of directives (since you have to add "AuthzMergeRules Off"
> in each sub-<Directory>) to achieve what seems to me to be a typical
> configuration, i.e., increasing security as you go down the tree.
>
> 2) Another option might be to use AND logic. In this case, if I'm
> applying the logic correctly, no one would be able to access
> /htdocs/team/admin given the configuration above in a 2.4 context
> (since "admin" isn't in "team"). While more secure, this also seems
> counter-intuitive to me. Maybe -0.5?
>
> 3) Finally there's the pre-2.4 logic of overriding all previous authz.
> This would seem to be the most preferable option, since it ensures
> many pre-2.4 configurations will continue to work as expected, and
> I think also reduces configuration verbosity in typical cases.
>
>
> You were concerned, I think, about more complex configurations
> like this:
>
>>> <Directory /www/pages>
>>> <SatisfyAll>
>>> Require ip 10.10.0.1
>>> Require ldap-group sales
>>> <SatisfyOne>
>>> Require ldap-group ne-sales
>>> Require ldap-group sw-sales
>>> </SatisfyOne>
>>> </SatisfyAll>
>>> </Directory>
>
>>> <Directory /www/pages/private>
>>> Require ldap-group marketing
>>> </Directory>
>
> I would suggest that the default pre-2.4 logic of overriding previous
> authz when any authz is defined in a per-dir block is still reasonable as
> a default. Thus, only those in "marketing" have access to
> /www/pages/private, and they can access it from other addresses than
> 10.10.0.1. Even if this isn't what is desired, it's clear enough that
> an administrator can figure out what's going on and why the configuration
> isn't achieving the desired result.
>
I'm OK with it up to this point.
> I'd propose giving the administrator the choice of both alternatives
> to the default logic. Instead of simply offering "AuthzMergeRules On",
> there would be two alternatives to the default "Off" condition. These
> would be "AuthzMergeRules SatisfyOne" (the OR logic) and
> "AuthzMergeRules SatisfyAll" (the AND logic).
>
> We might offer "Or" and "And" as synonyms for "SatisfyOne" and
> "SatisfyAll", respectively.
>
This is where it starts to go wrong for me. Where it gets confusing for somebody who is trying to figure out what the configuration is doing is:
<Directory /www/pages>
<SatisfyAll>
Require ip 10.10.0.1
Require ldap-group sales
<SatisfyOne>
Require ldap-group ne-sales
Require ldap-group sw-sales
</SatisfyOne>
</SatisfyAll>
</Directory>
<Directory /www/pages/private>
AuthzMergeRules SatisfyOne
<SatisfyAll>
Require ldap-group marketing
Require ldap-group alt-marketing
</SatisfyAll>
</Directory>
Now I have to reconcile the logic of the parent with the logic of both the AuthzMergeRules and the <SatisfyAll> tag. Even though it might not always look like the cleanest configuration, I think it will be less confusing if the logic rules were confined to the <SatisfyAll> and <SatisfyOne> tags rather than introducing alternate logic directives. At least with AuthzMergeRules being ON or OFF, the only thing I need to know is if I am merging with the parent or not. All of the logic rules just flow from there.
Brad
Re: AuthzMergeRules directive
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Brad Nicholes wrote:
> I'm not real excited about adding a new authz directive. Authn and
> authz are already very complex and adding a new directive to the mix will
> just help to confuse people even more.
That's a good point. Mostly the idea of an Accept replacement for
Require came up as a way to distinguish pre-2.4 and 2.4 per-dir authz,
and in case there were any "Require foo" directives which had slightly
different meanings in the two contexts and which might therefore trip
people up. If we can do without it, all the better.
> I am OK with this one except for the reason that I mentioned before.
> By allowing authz to be inherited even when AuthzMergeRules is OFF is
> kind of a conflict. In other words, since AuthzMergeRules OFF implies
> an AND, 1 AND 0 should be 0 or no authz rather than inherited authz.
> However I could buy into this if it seems to make more intuitive sense
> to the user.
Well, I may be missing something, but what I envisioned was that
AuthzMergeRules had three options: "Off" (i.e., inherited until overridden,
the pre-2.4 default), "SatisfyOne", and "SatisfyAll". That would give
administrators full control over how they wanted authz in different
per-dir blocks to be merged.
It seems to me we have three basic possibilities when it comes to
merging authz across per-dir blocks, and the most common authz case
to consider is going to be where security gets tighter as you move down
the document tree. Imagine something like the following in a pre-2.4
configuration, where "admin" is not a member of "team":
<Directory /htdocs>
## full access
</Directory>
<Directory /htdocs/team>
## anyone in "team" has access
Require group team
</Directory>
<Directory /htdocs/team/admin>
## only "admin" user has access
Require user admin
</Directory>
1) The first option for 2.4 merging is to use OR logic (the current
default in trunk). This leads to anyone in "team" having access to
/htdocs/team/admin, I believe. I think I'd have to vote -1 against
this, because it will lead to lots of previously secure configurations
becoming insecure. Plus it would seem to increase the required
number of directives (since you have to add "AuthzMergeRules Off"
in each sub-<Directory>) to achieve what seems to me to be a typical
configuration, i.e., increasing security as you go down the tree.
2) Another option might be to use AND logic. In this case, if I'm
applying the logic correctly, no one would be able to access
/htdocs/team/admin given the configuration above in a 2.4 context
(since "admin" isn't in "team"). While more secure, this also seems
counter-intuitive to me. Maybe -0.5?
3) Finally there's the pre-2.4 logic of overriding all previous authz.
This would seem to be the most preferable option, since it ensures
many pre-2.4 configurations will continue to work as expected, and
I think also reduces configuration verbosity in typical cases.
You were concerned, I think, about more complex configurations
like this:
>> <Directory /www/pages>
>> <SatisfyAll>
>> Require ip 10.10.0.1
>> Require ldap-group sales
>> <SatisfyOne>
>> Require ldap-group ne-sales
>> Require ldap-group sw-sales
>> </SatisfyOne>
>> </SatisfyAll>
>> </Directory>
>> <Directory /www/pages/private>
>> Require ldap-group marketing
>> </Directory>
I would suggest that the default pre-2.4 logic of overriding previous
authz when any authz is defined in a per-dir block is still reasonable as
a default. Thus, only those in "marketing" have access to
/www/pages/private, and they can access it from other addresses than
10.10.0.1. Even if this isn't what is desired, it's clear enough that
an administrator can figure out what's going on and why the configuration
isn't achieving the desired result.
I'd propose giving the administrator the choice of both alternatives
to the default logic. Instead of simply offering "AuthzMergeRules On",
there would be two alternatives to the default "Off" condition. These
would be "AuthzMergeRules SatisfyOne" (the OR logic) and
"AuthzMergeRules SatisfyAll" (the AND logic).
We might offer "Or" and "And" as synonyms for "SatisfyOne" and
"SatisfyAll", respectively.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: AuthzMergeRules directive
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/9/2008 at 11:08 AM, in message <47...@pearsoncmg.com>, Chris
Darroch <ch...@pearsoncmg.com> wrote:
> Chris Darroch wrote:
>
>> Here's another thought: for people doing mass virtual hosting,
>> and who let their customers put authn/z directives into .htaccess
>> files with "AllowOverride AuthConfig", I would think it may be
>> important to ensure that these rules still merge together in the
>> way they used to. Otherwise upgrading to 2.4 might mean tracking
>> down every .htaccess file and rewriting it to do the right thing
>> (sticking in an "AuthzMergeRules Off" or something). For some
>> people doing vhosting I suspect that would be a tall order, so it
>> would be good if 2.4 would function securely in this situation,
>> by default. That said, I don't use .htaccess files and may not
>> be making any sense today; my apologies.
>
> Here's a follow-up notion; admittedly, it represents a lot of
> re-refactoring work. It would provide an secure upgrade path for
> people with complex configurations, including those with many
> legacy .htaccess files to consider.
>
> A new directive, Accept, is introduced to take the place of
> Require. It functions as Require does now in 2.4. Thus we
> have two groups of authz directives, old (Require/Satisfy/Order/
> Deny/Allow) and new (Accept/Reject/<SatisfyOne>/<SatisfyAll>).
> The old directives function as they did in 2.2. Authz directives
> would be parsed and merged as follows:
>
I'm not real excited about adding a new authz directive. Authn and authz are already very complex and adding a new directive to the mix will just help to confuse people even more. Especially when they can't tell the difference between 'require' and 'accept' or when they should use one or the other. The requirement to stay somewhat backwards compatible in all of this stuff lends to the confusion already.
> 1) Within a per-dir config block (<Location>/<Directory>/etc.)
> old and new authz directives may not be mixed. If directives
> from both groups appear, a config-time error is thrown.
>
> 2) When merging new authz directives within a per-dir config
> block, the default merge rule is OR, as in 2.4 at present.
> This is equivalent to using a <SatisfyOne> around all new authz
> directives within a per-dir config block.
>
> 3) When merging per-dir config blocks at runtime, the following
> rules are applied; we'll call the parent block "base" and the
> child block "new":
>
> 3.1) If the new block contains no authz directives, the base's
> authz configuration is inherited (if any). This follows
> current 2.2 behaviour.
>
I am OK with this one except for the reason that I mentioned before. By allowing authz to be inherited even when AuthzMergeRules is OFF is kind of a conflict. In other words, since AuthzMergeRules OFF implies an AND, 1 AND 0 should be 0 or no authz rather than inherited authz. However I could buy into this if it seems to make more intuitive sense to the user.
> 3.2) If the new block contains old authz directives, the base
> block's authz configuration is discarded, and the new block's
> authz directives are applied to a clean slate. This follows
> current 2.2 behaviour.
>
> 3.3) If the new block contains new authz directives, the base
> and new blocks' authz configurations are merged using
> the rule specified by AuthzMergeRules (as it appears within
> the new block):
>
This is where things get a little confusing for me. I'm not really too excited about authz logic behavior changing just because of which version of an authz directive you used. This type of change in behavior isn't intuitive. At least with the way it is now,the behavior change would be between 2.2 and 2.4 rather than two different behaviors in 2.4 itself.
> 3.3.1) If AuthzMergeRules is set to Off or is not defined,
> the base block's authz configuration is discarded,
> and the new block's authz directives are applied to a
> clean slate. This follows current 2.2 behaviour, to avoid
> confusion and simplify most configurations.
>
> 3.3.2) If AuthzMergeRules is set to Or or SatisfyOne, the base
> block's authz configuration is merged with the new block's
> as if they were collectively contained within a <SatisfyOne>
> block.
>
> 3.3.3) If AuthzMergeRules is set to And or SatisfyAll, the base
> block's authz configuration is merged with the new block's
> as if they were collectively contained within a <SatisfyAll>
> block.
>
This could be OK however I'm not real comfortable with specifying the merging logic in two different ways. In other words, if AuthzMergeRules is set to OR yet <SatisfyAll> is also specified in the same block. The new authz directives may take a little getting used to when first used, but at least there is a consistent way to do things and a behavior that will be consistent in 2.4 without having to worry a lot about "what if"s.
> Writing that all out it mostly just seems like a depressingly
> large amount of work, but otherwise feels like it might offer a
> way forward, both for people upgrading from 2.2 and those starting
> fresh with 2.4. Thoughts?
>
In the end I am all for whatever will make life easier for the person who has to do configuration. The downside to authn and authz is that it has become more complex, the up side is that it has also become more powerful and predictable. I'm just not sure what the right compromise is.
Brad
Re: AuthzMergeRules directive
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Chris Darroch wrote:
> Here's another thought: for people doing mass virtual hosting,
> and who let their customers put authn/z directives into .htaccess
> files with "AllowOverride AuthConfig", I would think it may be
> important to ensure that these rules still merge together in the
> way they used to. Otherwise upgrading to 2.4 might mean tracking
> down every .htaccess file and rewriting it to do the right thing
> (sticking in an "AuthzMergeRules Off" or something). For some
> people doing vhosting I suspect that would be a tall order, so it
> would be good if 2.4 would function securely in this situation,
> by default. That said, I don't use .htaccess files and may not
> be making any sense today; my apologies.
Here's a follow-up notion; admittedly, it represents a lot of
re-refactoring work. It would provide an secure upgrade path for
people with complex configurations, including those with many
legacy .htaccess files to consider.
A new directive, Accept, is introduced to take the place of
Require. It functions as Require does now in 2.4. Thus we
have two groups of authz directives, old (Require/Satisfy/Order/
Deny/Allow) and new (Accept/Reject/<SatisfyOne>/<SatisfyAll>).
The old directives function as they did in 2.2. Authz directives
would be parsed and merged as follows:
1) Within a per-dir config block (<Location>/<Directory>/etc.)
old and new authz directives may not be mixed. If directives
from both groups appear, a config-time error is thrown.
2) When merging new authz directives within a per-dir config
block, the default merge rule is OR, as in 2.4 at present.
This is equivalent to using a <SatisfyOne> around all new authz
directives within a per-dir config block.
3) When merging per-dir config blocks at runtime, the following
rules are applied; we'll call the parent block "base" and the
child block "new":
3.1) If the new block contains no authz directives, the base's
authz configuration is inherited (if any). This follows
current 2.2 behaviour.
3.2) If the new block contains old authz directives, the base
block's authz configuration is discarded, and the new block's
authz directives are applied to a clean slate. This follows
current 2.2 behaviour.
3.3) If the new block contains new authz directives, the base
and new blocks' authz configurations are merged using
the rule specified by AuthzMergeRules (as it appears within
the new block):
3.3.1) If AuthzMergeRules is set to Off or is not defined,
the base block's authz configuration is discarded,
and the new block's authz directives are applied to a
clean slate. This follows current 2.2 behaviour, to avoid
confusion and simplify most configurations.
3.3.2) If AuthzMergeRules is set to Or or SatisfyOne, the base
block's authz configuration is merged with the new block's
as if they were collectively contained within a <SatisfyOne>
block.
3.3.3) If AuthzMergeRules is set to And or SatisfyAll, the base
block's authz configuration is merged with the new block's
as if they were collectively contained within a <SatisfyAll>
block.
Writing that all out it mostly just seems like a depressingly
large amount of work, but otherwise feels like it might offer a
way forward, both for people upgrading from 2.2 and those starting
fresh with 2.4. Thoughts?
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: AuthzMergeRules directive
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Brad Nicholes wrote:
> Your assumptions about how the 2.2 per-dir merging is correct.
> Unfortunately the same concepts no longer apply to 2.4. The reason
> why is this:
>
> <Directory /www/pages>
> <SatisfyAll>
> Require ip 10.10.0.1
> Require ldap-group sales
> <SatisfyOne>
> Require ldap-group ne-sales
> Require ldap-group sw-sales
> </SatisfyOne>
> </SatisfyAll>
> </Directory>
>
> <Directory /www/pages/images>
> ## still protected
> Dav filesystem
> </Directory>
>
> <Directory /www/pages/private>
> Require ldap-group marketing
> </Directory>
>
> Which ldap-group is overridden vs merged? Since the 2.2 authz had no
> concept of logic and was simply a list of require statements, it was
> very easy to add to the list or override an entry in the list. This
> is no longer the case. The require statements have to be merged
> according to some type of logic rules. Your suggestion would work
> if /www/pages/private simply reset and applied only the require
> statements it found in its own directory block (ie. AuthzMergeRules OFF),
> but picking the inherited logic apart and trying to rework it, won't
> really work.
Ideally, perhaps, it would be possible to throw a configuration-time
error indicating that there was ambiguity here. However, since it's
going to be effectively impossible to pre-determine all the possible
<Directory>, <Location>, etc. blocks which might apply to a particular
request (and in which order), that's not really possible.
As you say, picking things apart isn't going to work either.
One alternative is, as we've discussed, a default "AuthzMergeRules Off"
state which would blank the slate when a per-dir config block contained
any of Require/Reject/<SastifyAll>/<SastifyOne>.
What would happen, though, if the default merge rule between per-dir
configuration blocks was AND? (Within a block, OR would presumably
still make sense.) I have a head cold today, and so may be making
even less sense than usual, but I think this would at least ensure
that people's configurations got gradually "tighter" and more
restrictive as blocks were merged together down through the
location and directory hierarchies. It might take an administrator
a while after upgrading to figure out why they couldn't access
something anymore, but at least they wouldn't have opened anything
up unexpectedly.
> BTW, one of the main reasons why the logic operators were added
> to authz was to solve the problem that existed in 2.2. The problem
> was that if multiple require statements appeared in a single
> directory block or in a hierarchy, you never really knew in which
> order they were actually applied. Basically it came down to the
> order in which the authz modules happen to have been loaded.
And there's no easy way, I think, to "turn off" authz completely,
a "Require all granted" ... the 2.2 docs refer you to using "Sastify All"
and "Allow from all". 2.4 is much cleaner, no doubt.
My concern just really comes down to the fact that I'm fairly sure
that a default OR merge rule between per-dir configuration blocks will
lead people into thinking they've secured a subdirectory, when in fact
they haven't, because their more-secure rule will be silently
short-circuited by less-secure authz rules from above.
Here's another thought: for people doing mass virtual hosting,
and who let their customers put authn/z directives into .htaccess
files with "AllowOverride AuthConfig", I would think it may be
important to ensure that these rules still merge together in the
way they used to. Otherwise upgrading to 2.4 might mean tracking
down every .htaccess file and rewriting it to do the right thing
(sticking in an "AuthzMergeRules Off" or something). For some
people doing vhosting I suspect that would be a tall order, so it
would be good if 2.4 would function securely in this situation,
by default. That said, I don't use .htaccess files and may not
be making any sense today; my apologies. Thanks,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: AuthzMergeRules directive
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/8/2008 at 10:41 AM, in message <47...@pearsoncmg.com>, Chris
Darroch <ch...@pearsoncmg.com> wrote:
> Brad Nicholes wrote:
>
>> <Directory /www/pages>
>> Reject ip 127.0.0.1 //Or any other Require directive
>> </Directory>
>>
>> <Directory /www/pages/whatever>
>> ...
>> </Directory>
>>
>> Since the /www/pages/whatever directory did not specify any authz,
>> what should happen? If the AuthzMergeRules is OFF then what is the
>> authz for /www/pages/whatever? I'm not sure that 'all granted' is
>> correct but then neither is 'all denied'. Since the AuthzMergeRules
>> is OFF then merging the authz would be counter intuitive.
>> If AuthzMergeRules is ON then 127.0.0.1 is rejected and all
>> others are allowed. I guess the thinking was that leaving the
>> default ON would leave fewer unknowns however in some instances may
>> not be as intuitive.
>
> Well, again referring to my intuition based on configuring 2.2
> and prior servers, I would expect the /www/pages authz to cover
> everything under /www/pages (including /www/pages/whatever) unless
> I define other authz rules -- at which point, the corresponding authz
> slate is wiped clean for that subdirectory, and my local authz
> directives take effect. (Not all authz directives, mind you, just
> those which I'm overriding.)
>
> So I can do something like:
>
> <Directory /www/pages>
> Require valid-user
> </Directory>
>
> <Directory /www/pages/images>
> ## still protected
> Dav filesystem
> </Directory>
>
> <Directory /www/pages/private>
> Require user admin
> </Directory>
>
> One key to this behaviour, IIRC, is that all of the stock authz
> modules in 2.2 use the default merge_dir_config rules; that is,
> none of them define their own merge function and all just say:
>
> NULL, /* dir merger --- default is to override */
>
> Then the ap_merge_per_dir_configs() logic which gets applied
> when merging their per-directory configurations is to cause the
> ancestor's configuration to be inherited, unless there's a new
> per-directory configuration for the same module.
>
> The Require directive is, again IIRC, handled in the core
> per-directory configuration, and the logic in merge_core_dir_configs()
> is similar: duplicate the ancestor's configuration, and then
> override the inherited Require directives if there's a Require
> directive in the new per-directory configuration:
>
> if (new->ap_requires) {
> conf->ap_requires = new->ap_requires;
> }
>
> So I think the result is that each authz directive gets inherited
> down through the directory configurations, until something overrides
> it, at which point everything to do with that directive is started
> fresh. It's a relatively space-efficient configuration style,
> actually, because you only need to put in an authz directive if you're
> changing something from what's inherited.
>
> I hope I've described the existing situation accurately; at any rate,
> it seems to me to be a good way to structure the 2.4 authz merge rules.
> It would mean you mostly didn't need to specify AuthzMergeRules (saves
> typing and errors) and things are protected down through the directory
> hierarchy by default (also good) unless you specifically include a
> new authz directive, at which point that takes effect and is inherited
> downwards. So the default merge logic would be, I guess, neither AND
> nor OR but inherit-until-overridden.
>
> Chris.
Your assumptions about how the 2.2 per-dir merging is correct. Unfortunately the same concepts no longer apply to 2.4. The reason why is this:
<Directory /www/pages>
<SatisfyAll>
Require ip 10.10.0.1
Require ldap-group sales
<SatisfyOne>
Require ldap-group ne-sales
Require ldap-group sw-sales
</SatisfyOne>
</SatisfyAll>
</Directory>
<Directory /www/pages/images>
## still protected
Dav filesystem
</Directory>
<Directory /www/pages/private>
Require ldap-group marketing
</Directory>
Which ldap-group is overridden vs merged? Since the 2.2 authz had no concept of logic and was simply a list of require statements, it was very easy to add to the list or override an entry in the list. This is no longer the case. The require statements have to be merged according to some type of logic rules. Your suggestion would work if /www/pages/private simply reset and applied only the require statements it found in its own directory block (ie. AuthzMergeRules OFF), but picking the inherited logic apart and trying to rework it, won't really work.
BTW, one of the main reasons why the logic operators were added to authz was to solve the problem that existed in 2.2. The problem was that if multiple require statements appeared in a single directory block or in a hierarchy, you never really knew in which order they were actually applied. Basically it came down to the order in which the authz modules happen to have been loaded. By applying the authz through logical operators, it replaced the simple array of entries with a logic tree, which is why the API ap_requires() no longer exists. It also got rid of all of the AuthzXXXAuthoritative directives which were confusing.
Brad
Re: AuthzMergeRules directive
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Brad Nicholes wrote:
> <Directory /www/pages>
> Reject ip 127.0.0.1 //Or any other Require directive
> </Directory>
>
> <Directory /www/pages/whatever>
> ...
> </Directory>
>
> Since the /www/pages/whatever directory did not specify any authz,
> what should happen? If the AuthzMergeRules is OFF then what is the
> authz for /www/pages/whatever? I'm not sure that 'all granted' is
> correct but then neither is 'all denied'. Since the AuthzMergeRules
> is OFF then merging the authz would be counter intuitive.
> If AuthzMergeRules is ON then 127.0.0.1 is rejected and all
> others are allowed. I guess the thinking was that leaving the
> default ON would leave fewer unknowns however in some instances may
> not be as intuitive.
Well, again referring to my intuition based on configuring 2.2
and prior servers, I would expect the /www/pages authz to cover
everything under /www/pages (including /www/pages/whatever) unless
I define other authz rules -- at which point, the corresponding authz
slate is wiped clean for that subdirectory, and my local authz
directives take effect. (Not all authz directives, mind you, just
those which I'm overriding.)
So I can do something like:
<Directory /www/pages>
Require valid-user
</Directory>
<Directory /www/pages/images>
## still protected
Dav filesystem
</Directory>
<Directory /www/pages/private>
Require user admin
</Directory>
One key to this behaviour, IIRC, is that all of the stock authz
modules in 2.2 use the default merge_dir_config rules; that is,
none of them define their own merge function and all just say:
NULL, /* dir merger --- default is to override */
Then the ap_merge_per_dir_configs() logic which gets applied
when merging their per-directory configurations is to cause the
ancestor's configuration to be inherited, unless there's a new
per-directory configuration for the same module.
The Require directive is, again IIRC, handled in the core
per-directory configuration, and the logic in merge_core_dir_configs()
is similar: duplicate the ancestor's configuration, and then
override the inherited Require directives if there's a Require
directive in the new per-directory configuration:
if (new->ap_requires) {
conf->ap_requires = new->ap_requires;
}
So I think the result is that each authz directive gets inherited
down through the directory configurations, until something overrides
it, at which point everything to do with that directive is started
fresh. It's a relatively space-efficient configuration style,
actually, because you only need to put in an authz directive if you're
changing something from what's inherited.
I hope I've described the existing situation accurately; at any rate,
it seems to me to be a good way to structure the 2.4 authz merge rules.
It would mean you mostly didn't need to specify AuthzMergeRules (saves
typing and errors) and things are protected down through the directory
hierarchy by default (also good) unless you specifically include a
new authz directive, at which point that takes effect and is inherited
downwards. So the default merge logic would be, I guess, neither AND
nor OR but inherit-until-overridden.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: AuthzMergeRules directive
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/4/2008 at 4:33 PM, in message <47...@pearsoncmg.com>, Chris
Darroch <ch...@pearsoncmg.com> wrote:
> Brad Nicholes wrote:
>
>> So here was the thinking behind it when AuthzMergeRules was introduced.
>> Maybe there is still a bug here that needs to be addressed.
>>
>>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44C4E0FA.8060
> 205@apache.org%3e
>>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44CA3C33.6720
> .00AC.0@novell.com%3e
>
> I'm not sure it's a bug per se, but rather, an unexpected break from
> the intuition developed by administrators used to configuring 2.2.x and
> prior versions about how authorization cascades through configuration
> blocks. I may be wrong about this, but here's how I'd expect the
> example from your second thread to work. The example is:
>
> <Directory /www/pages>
> Reject ip 127.0.0.1
> </Directory>
>
> <Directory /www/pages/secure>
> Authtype Basic
> ...
> <SatisfyAll>
> Require valid-user
> Reject user joe
> </SatisfyAll>
> </Directory>
>
> My hunch is that prior to 2.2, the fundamental logic when merging
> authz rules across blocks was neither AND nor OR, but "reset".
> That is, it relies on the configuration walks to find the authz
> directives in the most closely relevant block. Those directives
> are then applied; what appeared in less relevant blocks is ignored.
> I haven't looked closely at the logic, but that's what seems to happen
> if you've got something like:
>
> <Directory /htdocs>
> Require valid-user
> </Directory>
> <Directory /htdocs/admin>
> Require user admin
> </Directory>
>
> So in your example, my "configuration intuition" suggest that only
> what appears in the <Directory /www/pages/secure> block applies to
> anything under /www/pages/secure, and that the "Reject ip 127.0.0.1"
> would just not applied at all to these URIs. So I'd expect that
> to access /www/pages/secure I'd need to be any valid user except "joe";
> whether I was connecting from 127.0.0.1 wouldn't matter.
>
> Now, within a block, having OR be the default merge logic would
> seem to make sense; if you want AND, you need <SatisfyAll>. So:
>
> <Directory /www/pages/secure>
> Require user betty
> Require user joe
> </Directory>
>
> means "betty" and "joe" alone have access, regardless of what applied
> to /www/pages. But if the following is also configured, then a "reset"
> rule across blocks would mean that it does what one expects; "betty"
> and "joe" would be rejected along with everyone else when attempting
> to access URIs under /www/pages/secure/really.
>
> <Directory /www/pages/secure/really>
> Require all denied
> </Directory>
>
> This would presumably work identically:
>
> <Directory /www/pages/secure/really>
> Reject all granted
> </Directory>
>
> Anyway, that's a bit of a shot in the dark. Hope it helps. Thanks,
>
> Chris.
So I believe that the behavior that you have described could be accomplished by just switching the default of AuthzMergeRules from ON to OFF. The only case that I am still worried about is the following:
<Directory /www/pages>
Reject ip 127.0.0.1 //Or any other Require directive
</Directory>
<Directory /www/pages/whatever>
...
</Directory>
Since the /www/pages/whatever directory did not specify any authz, what should happen? If the AuthzMergeRules is OFF then what is the authz for /www/pages/whatever? I'm not sure that 'all granted' is correct but then neither is 'all denied'. Since the AuthzMergeRules is OFF then merging the authz would be counter intuitive. If AuthzMergeRules is ON then 127.0.0.1 is rejected and all others are allowed. I guess the thinking was that leaving the default ON would leave fewer unknowns however in some instances may not be as intuitive.
Brad
Re: AuthzMergeRules directive
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Brad Nicholes wrote:
> So here was the thinking behind it when AuthzMergeRules was introduced.
> Maybe there is still a bug here that needs to be addressed.
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44C4E0FA.8060205@apache.org%3e
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44CA3C33.6720.00AC.0@novell.com%3e
I'm not sure it's a bug per se, but rather, an unexpected break from
the intuition developed by administrators used to configuring 2.2.x and
prior versions about how authorization cascades through configuration
blocks. I may be wrong about this, but here's how I'd expect the
example from your second thread to work. The example is:
<Directory /www/pages>
Reject ip 127.0.0.1
</Directory>
<Directory /www/pages/secure>
Authtype Basic
...
<SatisfyAll>
Require valid-user
Reject user joe
</SatisfyAll>
</Directory>
My hunch is that prior to 2.2, the fundamental logic when merging
authz rules across blocks was neither AND nor OR, but "reset".
That is, it relies on the configuration walks to find the authz
directives in the most closely relevant block. Those directives
are then applied; what appeared in less relevant blocks is ignored.
I haven't looked closely at the logic, but that's what seems to happen
if you've got something like:
<Directory /htdocs>
Require valid-user
</Directory>
<Directory /htdocs/admin>
Require user admin
</Directory>
So in your example, my "configuration intuition" suggest that only
what appears in the <Directory /www/pages/secure> block applies to
anything under /www/pages/secure, and that the "Reject ip 127.0.0.1"
would just not applied at all to these URIs. So I'd expect that
to access /www/pages/secure I'd need to be any valid user except "joe";
whether I was connecting from 127.0.0.1 wouldn't matter.
Now, within a block, having OR be the default merge logic would
seem to make sense; if you want AND, you need <SatisfyAll>. So:
<Directory /www/pages/secure>
Require user betty
Require user joe
</Directory>
means "betty" and "joe" alone have access, regardless of what applied
to /www/pages. But if the following is also configured, then a "reset"
rule across blocks would mean that it does what one expects; "betty"
and "joe" would be rejected along with everyone else when attempting
to access URIs under /www/pages/secure/really.
<Directory /www/pages/secure/really>
Require all denied
</Directory>
This would presumably work identically:
<Directory /www/pages/secure/really>
Reject all granted
</Directory>
Anyway, that's a bit of a shot in the dark. Hope it helps. Thanks,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
AuthzMergeRules directive (was:Re: 2.4)
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/4/2008 at 11:37 AM, in message <47...@pearsoncmg.com>, Chris
Darroch <ch...@pearsoncmg.com> wrote:
> William A. Rowe, Jr. wrote:
>
>>> I've been working with the 2.4 authn/z stuff a bit lately and
>>> what I keep tripping over is that the default authorization merge rule
>>> uses OR logic. For example, if I enable mod_access_compat and
>>> put in a traditional:
>>
>> I wonder if anyone would offer a fastfeather talk next week on wed or
>> thurs - it's only 15 minutes - to introduce what's upcoming in 2.4?
>
> I won't be there, but here's a recap of the issue for discussion.
> (Caveat: I may be missing something important!)
>
> With 2.2 and prior versions, one can do something like:
>
> <Directory /htdocs>
> Require valid-user
> </Directory>
> <Directory /htdocs/admin>
> Require user admin
> </Directory>
>
> The logic which is then applied is:
>
> 1) For all requests under /htdocs, except those under /htdocs/admin,
> require any valid user.
> 2) For all requests under /htdocs/admin, require the "admin" user.
>
> With 2.4, unless I'm missing something, the same configuration
> produces the logic:
>
> 1) For all requests under /htdocs, except those under /htdocs/admin,
> require any valid user.
> 2) For all requests under /htdocs/admin, require any valid user OR
> require the user "admin". Of course this grants any valid user access.
>
> To get the old behaviour, you seem to need to add
> "AuthzMergeRules Off" to the second <Directory>. I just tested
> versions of this configuration with 2.2 and 2.4 and I think I'm
> describing the situation correctly. Assuming I am, I fear this
> will surprise a lot of people who think they've secured their
> systems after upgrading. It certainly caught me short.
>
> Perhaps the default AuthzMergeRules setting should be Off rather
> than On, at least when merging across configuration blocks?
>
So here was the thinking behind it when AuthzMergeRules was introduced. Maybe there is still a bug here that needs to be addressed.
http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44C4E0FA.8060205@apache.org%3e
http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44CA3C33.6720.00AC.0@novell.com%3e
Brad
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by Chris Darroch <ch...@pearsoncmg.com>.
William A. Rowe, Jr. wrote:
>> I've been working with the 2.4 authn/z stuff a bit lately and
>> what I keep tripping over is that the default authorization merge rule
>> uses OR logic. For example, if I enable mod_access_compat and
>> put in a traditional:
>
> I wonder if anyone would offer a fastfeather talk next week on wed or
> thurs - it's only 15 minutes - to introduce what's upcoming in 2.4?
I won't be there, but here's a recap of the issue for discussion.
(Caveat: I may be missing something important!)
With 2.2 and prior versions, one can do something like:
<Directory /htdocs>
Require valid-user
</Directory>
<Directory /htdocs/admin>
Require user admin
</Directory>
The logic which is then applied is:
1) For all requests under /htdocs, except those under /htdocs/admin,
require any valid user.
2) For all requests under /htdocs/admin, require the "admin" user.
With 2.4, unless I'm missing something, the same configuration
produces the logic:
1) For all requests under /htdocs, except those under /htdocs/admin,
require any valid user.
2) For all requests under /htdocs/admin, require any valid user OR
require the user "admin". Of course this grants any valid user access.
To get the old behaviour, you seem to need to add
"AuthzMergeRules Off" to the second <Directory>. I just tested
versions of this configuration with 2.2 and 2.4 and I think I'm
describing the situation correctly. Assuming I am, I fear this
will surprise a lot of people who think they've secured their
systems after upgrading. It certainly caught me short.
Perhaps the default AuthzMergeRules setting should be Off rather
than On, at least when merging across configuration blocks?
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re:
Dynamicconfiguration for the hackathon?])
Posted by Brad Nicholes <bn...@novell.com>.
>>> On 4/4/2008 at 1:20 AM, in message <47...@rowe-clan.net>, "William
A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> Chris Darroch wrote:
>>
>> I've been working with the 2.4 authn/z stuff a bit lately and
>> what I keep tripping over is that the default authorization merge rule
>> uses OR logic. For example, if I enable mod_access_compat and
>> put in a traditional:
>
> I wonder if anyone would offer a fastfeather talk next week on wed or
> thurs - it's only 15 minutes - to introduce what's upcoming in 2.4?
>
I won't be there, but you could use the tail end of my auth architecture slides that talk about the authz refactor. http://people.apache.org/~bnicholes/presentations/ApacheconUS2007_autharch.ppt
Brad
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Chris Darroch wrote:
>
> I've been working with the 2.4 authn/z stuff a bit lately and
> what I keep tripping over is that the default authorization merge rule
> uses OR logic. For example, if I enable mod_access_compat and
> put in a traditional:
I wonder if anyone would offer a fastfeather talk next week on wed or
thurs - it's only 15 minutes - to introduce what's upcoming in 2.4?
Bill
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by Chris Darroch <ch...@pearsoncmg.com>.
William A. Rowe, Jr. wrote:
> I'd -1 a 2.4.0 release today, because nobody has even bothered to make
> a candidate for 2.3-dev. Auth logic changes break most if not all third
> party auth modules (broke an auth feature in mod_ftp). Not talking about
> commercial modules .... but every third party auth extension out there.
I've been working with the 2.4 authn/z stuff a bit lately and
what I keep tripping over is that the default authorization merge rule
uses OR logic. For example, if I enable mod_access_compat and
put in a traditional:
<Location /foo>
Order deny,allow
Deny from all
</Location>
it doesn't take effect, because the default top-level <Directory>
contains "Require all granted" and since that succeeds for all
requests, everything else is short-circuited by the OR merge logic.
So at a minimum I seem to have to put in an "AuthzMergeRules Off" to
get things to DWIM.
I fear that might trip up a significant percentage of people
upgrading ... perhaps a "AuthzMergeRules Off" in the default httpd.conf
would be sufficient, but my experience with mod_authz_dbd suggested
that I needed to put it in a lot of places to get stuff working
the way I intended (e.g., the example config in the mod_authz_dbd
manual page in the trunk docs).
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
>
> But before that, we need a vision of where we're going,
> and how to get there without breaking what we've got.
* server_conf goes away. Modules have zero or more "conf" sections,
essentially today's misnamed dir_conf, which are initialized and
merged as they are today. Either using simple-wrappers or custom.
* we lose nothing, any module can rerun the conf merge conditionally
(see mod_proxy today, or method, or the new <if implementation).
* modules may pre-merge things to optimize them. E.g. mod_vhost will
pre-merge all of our <VirtualHosts > such that there is no run time
penalty for vhosts.
* particular merges should remain, as they are today, as a modular
assemblage of features. If your server will never serve files, there
is no reason to compile in mod_filesystem e.g. <Files and <Dir mergers.
No mod_vhost? Then no <VirtualHost support.
*** there must be sufficient hooks so that a lua, perl or m4 wrapper
can participate in parsing the config. TBD if that exists today.
> I don't see any such vision in this discussion.
Go back to my post from last night. Not saying there's agreement, just
some vision.
I know folks are thinking "wow, I want to put my favorite [Lua] language
parser into httpd core!" Well that's fine for some users, but at the
very same time, you have a huge crowd of perl users, mod_macro users, etc.
Based on httpd's design, you are SUPPOSED to be able to plug whichever
wrapper you like into the core. Overloading the core is taking httpd
into an entirely different direction. Just look at the effort we've
already expended is splitting cache from proxy, auth components from
one another, proxy capabilities from one monolithic module.
For that matter, plug in an XML syntax parser. We aren't quite there
because we don't have the concept of named-arguments. Fix that across
the entire spectrum of modules. E.g. instead of TAKE2, we have some
tuple for alias such as (TAKE2, "uri-path", "file-path", NULL) which
will facilitate more deliberate parsers and conf authoring. And that
is without breaking today's syntax.
Bill
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by Nick Kew <ni...@webthing.com>.
On Thu, 03 Apr 2008 11:13:31 -0500
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> The <If logic doesn't even apply when that module isn't loaded, I'd
> hope. Those admins who refuse to let their junior admins use that
> directive should have a level of control over their outward facing
> heavily-loaded machines :)
The <If> logic is approximately cloned from <Files>, and just
differs in what it evaluates.
If we're talking about any substantial config changes, then
the whole location_walk and merges should be on the table.
But before that, we need a vision of where we're going,
and how to get there without breaking what we've got.
I don't see any such vision in this discussion.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On Thu, Apr 3, 2008 at 8:53 AM, Akins, Brian <Br...@turner.com> wrote:
>> Very rough draft. But this is not necessarily slooooow... ;)
>
> Right.
>
> Even then, the user/admin may be willing to burn CPU cycles anyway to
> get a simpler config. Plus, if they were to use mod_rewrite, they've
> already blown a huge chunk of CPU cycles! =) -- justin
Yes! I'm not against offering slow features :)
I'm only antagonistic towards replacing the fast ones, from today.
FYI - Files and Directory should be entirely moved out of core into our
default filesystem provider module. Only host/location/method should be
part of the core (well, host perhaps in the http layer).
The <If logic doesn't even apply when that module isn't loaded, I'd hope.
Those admins who refuse to let their junior admins use that directive
should have a level of control over their outward facing heavily-loaded
machines :)
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Apr 3, 2008 at 8:53 AM, Akins, Brian <Br...@turner.com> wrote:
> Very rough draft. But this is not necessarily slooooow... ;)
Right.
Even then, the user/admin may be willing to burn CPU cycles anyway to
get a simpler config. Plus, if they were to use mod_rewrite, they've
already blown a huge chunk of CPU cycles! =) -- justin
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re:
Dynamic configuration for the hackathon?])
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/3/08 11:38 AM, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>> <If HTTP_Method == GET>
>> ...
>> </If>
>
> Slooooooooooooooooooooow
Not if the parsing is done at config time and HTTP_Method is handle by a
provider. Some pseudo code:
At config time, the parser would do something like:
parse_provider *prov;
void *data;
prov = ap_lookup_provider("config_parse", "HTTP_Method", "0.1");
data = prov->init(conf_pool, "HTTP_Method", TOKEN_EQUAL, "GET")
/*the provider may do something like*/
typedef struct {
parse_token token;
int method_number;
} method_data;
void *method_init(apr_pool_t *pool, const char *key, parse_token token,
const char *arg) {
method_data *data = apr_pcalloc(pool, sizeof(method_data));
data->token = token; /*need to check if we only handle === or something
*/
if(strcacecmp(arg, "GET")) {
data->method_number = M_GET;
}
return data;
/*the parser stores this data with the node*/
At run time, then when running this node from the cached parse tree, it may
call something like:
node->prov->exec(r, nod->data)
/*the provider runs something like*/
int method_exec(reuqest_rec *r, method_data *data) {
if(data->method_number == r->method_number)
return 1;
return 0;
}
Very rough draft. But this is not necessarily slooooow... ;)
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Akins, Brian wrote:
> On 4/3/08 10:47 AM, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>> I'll commit the <Method >
>
> <If HTTP_Method == GET>
> ...
> </If>
Slooooooooooooooooooooow
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re:
Dynamic configuration for the hackathon?])
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/3/08 10:47 AM, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> I'll commit the <Method >
<If HTTP_Method == GET>
...
</If>
;)
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Plüm wrote:
>
> 2. My feeling regarding the usage of 2.2 is that since about 6 month we are getting
> track as commercial 3rd parties now supply modules for httpd 2.2. This means that
> will have to maintain one more stable branch for quite some time and to be honest
> currently we effectively manage only one since 1.3 and also 2.0 seem to be pretty
> abandoned. I am not quite sure if we have enough resources to do this.
Perhaps 1.3 is maintained, perhaps not, just depending on if there
are enough developers who care to provide minor patches. But it
really shouldn't be a distraction.
Once folks accept 2.2 as a clean replacement for 2.0 (we are essentially
there now, I think, perhaps after one or two more point-bumps), 2.0 should
fall off the radar entirely.
This 2.2 becomes stable, so we are really only talking about supporting
a 2.2 and a 2.4 for a while, then 2.4 and a 3.0.
I'd -1 a 2.4.0 release today, because nobody has even bothered to make
a candidate for 2.3-dev. Auth logic changes break most if not all third
party auth modules (broke an auth feature in mod_ftp). Not talking about
commercial modules .... but every third party auth extension out there.
The only thing I'd like to change before we push 2.3-dev onto our module
developer community is to enhance the methods logic (64 is now insufficient
when you add DAV + FTP + {whatever} into the method stew) and drop the
<Limit > directive already for the <Method > directive. These have some
subtle auth-changes that a few auth module authors need to compensate for.
(The third party auth modules that won't change are the ones that are
already broken for <Limit > ... who won't have to do anything special in
support of the <Method > directive.)
I'll commit the <Method > changes before the hackathon so that folks can
corner me in person, dev@ list feedback will also be welcome as always.
Just to prove I'm not being a prick with respect to Lua support, I'm working
on <Method > as an add in module ;-)
Bill
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 3, 2008, at 12:32 PM, Brad Nicholes wrote:
>>>>
> It wouldn't surprise me, which is why we need to get a 2.3-beta out
> there for testing.
That would be good as well... that way we can determine
how solid the existing impl is, so when the new stuff is
added we know the "old" stuff is still good :)
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re:
Dynamic configuration for the hackathon?])
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/3/2008 at 8:23 AM, in message
<99...@VF-MBX11.internal.vodafone.com>,
Plüm,
Rüdiger, VF-Group <ru...@vodafone.com> wrote:
>
>> -----Ursprüngliche Nachricht-----
>> Von: Jim Jagielski
>> Gesendet: Donnerstag, 3. April 2008 16:07
>> An: dev@httpd.apache.org
>> Betreff: 2.4 (Was: Re: Configuration Issues to Address [was
>> Re: Dynamic configuration for the hackathon?])
>>
>> Another good topic of discussion:
>>
>> Time for a 2.4 release? I wouldn't mind pushing that along
>> and get some of the feature-set of 2.4 out before we do too
>> much ripping with the inevitable delays associated with that :)
>>
>
> I know that I am always devils advocate and a brakeman regarding
this,
> but we should keep in mind the following:
>
> 1. After the rewrite of the authz code to a provider based model we
still
> fail
> the basic authz tests in the perl framework. This is a clear
showstopper
> and needs to be fixed first. Yes, I also should have a had a more
closer
> look on what Brad (no blame game intended against anyone as I
failed to
> do
> proper review back then) did there in the past to highlight issues
> earlier,
> but my gut feeling tells me that there are still some surprises in
this
> code
> regarding bugs and the configuration syntax.
>
It wouldn't surprise me, which is why we need to get a 2.3-beta out
there for testing. I've tried to make sure that the holes where filled
with the authz refactor, but it is likely that something will be missing
until more wide spread testing is done. The perl framework problems
were discussed on the list a couple of months ago
http://mail-archives.apache.org/mod_mbox/httpd-dev/200801.mbox/%3c7e79c5b90801040912h187004a6wea8d1b51cc1d46db@mail.gmail.com%3e
The current tests don't apply anymore because authz has moved from hook
based to provider based with logic operators added. If we need to
rework something outside of the tests themselves, then that needs to be
identified. As far as breaking existing authz modules, it is a similar
situation when authn moved from hooks to providers in 2.2. All of the
standard Apache authz modules have already been refactored. This issue
is third parties will have to refactor their authz modules for 2.4.
Brad
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski
> Gesendet: Donnerstag, 3. April 2008 16:07
> An: dev@httpd.apache.org
> Betreff: 2.4 (Was: Re: Configuration Issues to Address [was
> Re: Dynamic configuration for the hackathon?])
>
> Another good topic of discussion:
>
> Time for a 2.4 release? I wouldn't mind pushing that along
> and get some of the feature-set of 2.4 out before we do too
> much ripping with the inevitable delays associated with that :)
>
I know that I am always devils advocate and a brakeman regarding this,
but we should keep in mind the following:
1. After the rewrite of the authz code to a provider based model we still fail
the basic authz tests in the perl framework. This is a clear showstopper
and needs to be fixed first. Yes, I also should have a had a more closer
look on what Brad (no blame game intended against anyone as I failed to do
proper review back then) did there in the past to highlight issues earlier,
but my gut feeling tells me that there are still some surprises in this code
regarding bugs and the configuration syntax.
2. My feeling regarding the usage of 2.2 is that since about 6 month we are getting
track as commercial 3rd parties now supply modules for httpd 2.2. This means that
will have to maintain one more stable branch for quite some time and to be honest
currently we effectively manage only one since 1.3 and also 2.0 seem to be pretty
abandoned. I am not quite sure if we have enough resources to do this.
Regards
Rüdiger
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Posted by Jorge Schrauwen <jo...@gmail.com>.
On Thu, Apr 3, 2008 at 4:31 PM, Mads Toftum <ma...@toftum.dk> wrote:
> On Thu, Apr 03, 2008 at 10:06:50AM -0400, Jim Jagielski wrote:
> > Time for a 2.4 release? I wouldn't mind pushing that along
> > and get some of the feature-set of 2.4 out before we do too
> > much ripping with the inevitable delays associated with that :)
>
> Is there really enough news in trunk to warrant the overhead of
> maintaining yet another branch? tbh. I'd much rather see work going
> towards 3.x ;)
>
> vh
>
> Mads Toftum
> --
> http://soulfood.dk
>
I'm wondering the same.
--
~Jorge
Re: 2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?])
Posted by Mads Toftum <ma...@toftum.dk>.
On Thu, Apr 03, 2008 at 10:06:50AM -0400, Jim Jagielski wrote:
> Time for a 2.4 release? I wouldn't mind pushing that along
> and get some of the feature-set of 2.4 out before we do too
> much ripping with the inevitable delays associated with that :)
Is there really enough news in trunk to warrant the overhead of
maintaining yet another branch? tbh. I'd much rather see work going
towards 3.x ;)
vh
Mads Toftum
--
http://soulfood.dk
2.4 (Was: Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?])
Posted by Jim Jagielski <ji...@jaguNET.com>.
Another good topic of discussion:
Time for a 2.4 release? I wouldn't mind pushing that along
and get some of the feature-set of 2.4 out before we do too
much ripping with the inevitable delays associated with that :)
Re: Configuration Issues to Address [was Re: Dynamic configuration
for the hackathon?]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jorge Schrauwen wrote:
>> ... if we had a config finalize, modules who were prepared to declare
>> their config (e.g. mod_vhost declaring the per-host directory merges
>> "completed") then as-root, we can finish these out, opening logs with
>> full privileges. Other merges will happen at run time (or be optimized
>> when we can accomplish this) per-request.
>
> So does a setup like this make it possible for the processes/thread
> handling the request to change to the correct UID/GID before
> reading/writing files? Just something that popped into my head when
> reading this.
No. Once the httpd engine finishes the config phase altogether, we
continue to drop from root to the desired UID/GID and that process
must not have the privilege to change these again. The request engine
... which is the container where exploits are targeted, must remain
secure.
Re: Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?]
Posted by Jorge Schrauwen <jo...@gmail.com>.
> ... if we had a config finalize, modules who were prepared to declare
> their config (e.g. mod_vhost declaring the per-host directory merges
> "completed") then as-root, we can finish these out, opening logs with
> full privileges. Other merges will happen at run time (or be optimized
> when we can accomplish this) per-request.
So does a setup like this make it possible for the processes/thread
handling the request to change to the correct UID/GID before
reading/writing files? Just something that popped into my head when
reading this.
--
~Jorge
Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?]
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/2/08 6:07 PM, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> we can finish these out, opening logs with
> full privileges. Other merges will happen at run time (or be optimized
> when we can accomplish this) per-request.
We already "fake" per-dir logs with the env stuff in mod_log_config.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Configuration Issues to Address [was Re: Dynamic configuration
for the hackathon?]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> William A. Rowe, Jr. wrote:
>>
>>> -I have to write a good bit of code before a module is configurable.
>>> (I'm
>>> lazy. Very lazy.)
>>
>> Agreed - see my first point.
>>
>> One interesting point; why do we keep per-server and per-dir sections?
>> Perhaps it's time for a single simpler-to-use mechanic which can
>> represent
>> either or both (essentially deprecate per-server in 3.0).
>
> I'm pondering this... if we drop "per-server" ... yet retain the ability
> for authors to factor their config info into related config sections...
>
> ... we could divide the frequently-merged and infrequently-merged options
> into two or more groups; the overall merge calls would run more quickly,
> but the flexibility would be greatly enhanced.
>
> Override-able ->document_root, anyone?
And taking this one step further - addressing issues such as the fact that
we all want certain merged-sections (e.g. vhosts) to be run as root early
in the process, but be flexible enough to override a bit later on...
... if we had a config finalize, modules who were prepared to declare
their config (e.g. mod_vhost declaring the per-host directory merges
"completed") then as-root, we can finish these out, opening logs with
full privileges. Other merges will happen at run time (or be optimized
when we can accomplish this) per-request.
It's not looking trivial, but it seems doable.
Re: Configuration Issues to Address [was Re: Dynamic configuration
for the hackathon?]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Akins, Brian wrote:
> On 4/3/08 11:38 AM, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>> But that *doesn't* mean I don't want it... simply not to replace directory,
>> file, location or method. Keep in mind you wouldn't have your ErrorLog
>> opened at startup time, as this is too variant
>
> Unless I'm mistaken, there is nothing that really stops us from making all
> log related directives from being per-dir (assuming they have "real" names
> at startup).
>
> Using mod_log_config as an example, it opens all of it's logs as root at
> start, and we are able to select one at run time via env. That could just
> as easily be done via a per-dir merge.
>
> (Note: I am ignorant of the stuff between the errolog directive until it
> gets to the actually logging stuff, so I may be way off. )
You are right; provided that we pre-merge SOME of the layers of dir configs
(e.g. we pre-merge all of the vhost-related dir configs).
And remember a merge of A+null or null+A is fast. So if we break up a very
very big dir config structure into three, e.g. those directives that are
very frequently tweaked, those which are sometimes tweaked and those we
don't expect to change at all (at least, not after server-merges at startup)
the overall hit of dir_merge (now three different functions for this
hypothetical modules) will be much less.
Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?]
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/3/08 11:38 AM, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> But that *doesn't* mean I don't want it... simply not to replace directory,
> file, location or method. Keep in mind you wouldn't have your ErrorLog
> opened at startup time, as this is too variant
Unless I'm mistaken, there is nothing that really stops us from making all
log related directives from being per-dir (assuming they have "real" names
at startup).
Using mod_log_config as an example, it opens all of it's logs as root at
start, and we are able to select one at run time via env. That could just
as easily be done via a per-dir merge.
(Note: I am ignorant of the stuff between the errolog directive until it
gets to the actually logging stuff, so I may be way off. )
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Configuration Issues to Address [was Re: Dynamic configuration
for the hackathon?]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Akins, Brian wrote:
> On 4/2/08 5:56 PM, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>> I'm pondering this... if we drop "per-server" ... yet retain the ability
>> for authors to factor their config info into related config sections...
>
> Yes... Bcs what IO am imagining is something like what I've posted before:
>
> <If HTTP_HEADER{'Host'} == www.cnn.com and Port == 8080>
> DocumentRoot /www/cnn
> ServerAdmin someone@domain.com
> etc....
>
> <If Location == /my/prefix>
> Foo bar
> </If>
> </If>
>
> Maybe no need for Directory, location, etc, either...
horribly inefficient, on a 10-fold order of magnitude.
But that *doesn't* mean I don't want it... simply not to replace directory,
file, location or method. Keep in mind you wouldn't have your ErrorLog
opened at startup time, as this is too variant (unless the ErrorLog code
became really very clever - although dynamic patterns in the ErrorLog file
name could also make that impossible) ... but where you are very cautious
about your log file directive, and it's not a mass vhosting server, this
really wouldn't prove to be an issue.
Bill
Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?]
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/2/08 5:56 PM, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> I'm pondering this... if we drop "per-server" ... yet retain the ability
> for authors to factor their config info into related config sections...
Yes... Bcs what IO am imagining is something like what I've posted before:
<If HTTP_HEADER{'Host'} == www.cnn.com and Port == 8080>
DocumentRoot /www/cnn
ServerAdmin someone@domain.com
etc....
<If Location == /my/prefix>
Foo bar
</If>
</If>
Maybe no need for Directory, location, etc, either...
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Configuration Issues to Address [was Re: Dynamic configuration
for the hackathon?]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
>> -I have to write a good bit of code before a module is configurable. (I'm
>> lazy. Very lazy.)
>
> Agreed - see my first point.
>
> One interesting point; why do we keep per-server and per-dir sections?
> Perhaps it's time for a single simpler-to-use mechanic which can represent
> either or both (essentially deprecate per-server in 3.0).
I'm pondering this... if we drop "per-server" ... yet retain the ability
for authors to factor their config info into related config sections...
... we could divide the frequently-merged and infrequently-merged options
into two or more groups; the overall merge calls would run more quickly,
but the flexibility would be greatly enhanced.
Override-able ->document_root, anyone?
Bill
Re: Configuration Issues to Address [was Re: Dynamic
configuration for the hackathon?]
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/2/08 5:50 PM, "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> ixnay on the run-time intensive, slow down the server sorts of changes.
> httpd continues to become slower as it becomes more powerful. I know you
> are the first one to raise your hand and point out when we are doing too
> much processing for too simple a request. Isn't this what modules are for?
>
> Perhaps you could elaborate?
Yes, there is always a fine line between configuration and performance, I
suppose.
Basically, at the heart of what I'm imagining is everything is per_dir (no
real per-server configs) and the "fancy configuration stuff" really boils
down to per-dir config merges. The "parser" or "language" needs to be small
and quick and do most of it's heavy lifting in post-config (parse and cache
the tree, don't do the full string parsing at run time). Sorta how
mod_rewrite works now... The If/Else stuff would probably be able to do
this..
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Configuration Issues to Address [was Re: Dynamic configuration for
the hackathon?]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Akins, Brian wrote:
>
> The biggest problems I have with current system are:
> -Every module does things differently
Within limits this will remain true. But we are missing a host of very
trivial simplifications for the casual module developer, and reinvent the
same wheel module after module.
I'm going to propose some changes to the default TAKE[0-9]+ macro and
support functions to illustrate how much more useful these can be, and
offer some new functions that make it really simple to
* define constraints (an int, sure, but in what range?)
* tag default-value, and error out if a non-default value is replaced
by the user (e.g. LogLevel debug ........ LogLevel error later on)
> -No real per-request configuration. Some modules use env to do some of
> this.
ixnay on the run-time intensive, slow down the server sorts of changes.
httpd continues to become slower as it becomes more powerful. I know you
are the first one to raise your hand and point out when we are doing too
much processing for too simple a request. Isn't this what modules are for?
Perhaps you could elaborate?
> -I have to write a good bit of code before a module is configurable. (I'm
> lazy. Very lazy.)
Agreed - see my first point.
One interesting point; why do we keep per-server and per-dir sections?
Perhaps it's time for a single simpler-to-use mechanic which can represent
either or both (essentially deprecate per-server in 3.0).
> If we do what niq suggests (which, if we stick with current config system is
> fine) is that it just adds another layer on top of all the existing issues.
>
> With lua, for example you could make modules Lua modules... Maybe could do
> same in perl??
That's why I'm not a fan of all lua all the time. But to do what we all
want, I bet we'll need to refine the config API, and simplify it for adding
pluggable semantic engines (lua, perl, simply 'sed' etc).
> My opinion (which is worthless, I know) is to pick one way and do it. Lua
> is easy to learn and satisfies most (all?) of our requirements. And if
> Brian M. and I can learn it, anyone can ;)
Most importantly, if I am building an embedded httpd, I don't want all of
this extra crap. httpd was famous for how lean it could be, are we all
ready to throw out that advantage?
Re: Dynamic configuration for the hackathon?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Apr 1, 2008 at 6:20 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> IMO, we work best when we feel empowered to scratch our itches...
> As we've also seen, sometimes all it takes is someone to create
> a rough framework of an implementation for people to get excited
> by it and jump right on in, adding, extending and tuning it.
>
> This reminds me: a serf BOF or session would, I think, go over
> quite well :)
Lieven and I are going to be focusing on cutting a serf release during
the Hackathon. I promised that we'd get a new serf release out before
Subversion 1.5 final comes out. =P
If folks are interested in a serf BOF or 'beer session' at the bar,
I'm sure we could swing something. =) -- justin
Re: [OT] Dynamic configuration for the hackathon?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Jorge Schrauwen wrote:
> On Tue, Apr 1, 2008 at 4:13 PM, Issac Goldstand <ma...@beamartyr.net> wrote:
>>
>>
>> >
>> > Downside:
>> > - perl isn't very easy and userfriendly
>>
>> I think that the downside is the fact that perl interpreters suck up
>> RAM, not the easiness factor. It's probably not significantly
>> easier/harder than lua, but it's big and clunky
>>
>
> Well perl did scare the *bleep* out of my class mates when they where
> looking what I was doing during the break.
>
Isn't that why we love it so much? :)
Issac
Re: Dynamic configuration for the hackathon?
Posted by Jorge Schrauwen <jo...@gmail.com>.
On Tue, Apr 1, 2008 at 4:13 PM, Issac Goldstand <ma...@beamartyr.net> wrote:
>
>
>
> Jorge Schrauwen wrote:
> > Solutions propose:
> > - lua in the core or atleast in a module
> > - mod_perl
>
> mod_perl exists already. We're looking to replace it because... (see below)
>
I'm quite aware that it exists, I ment that it is a possible solution
to the problem.
(I'm actually using it... although restarts are still needed to load
the new vhosts)
>
> >
> > Downside:
> > - perl isn't very easy and userfriendly
>
> I think that the downside is the fact that perl interpreters suck up
> RAM, not the easiness factor. It's probably not significantly
> easier/harder than lua, but it's big and clunky
>
Well perl did scare the *bleep* out of my class mates when they where
looking what I was doing during the break.
Then again, I do most of my system scripts in perl ^^
> Issac
>
>
--
~Jorge
Re: Dynamic configuration for the hackathon?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Jorge Schrauwen wrote:
> Solutions propose:
> - lua in the core or atleast in a module
> - mod_perl
mod_perl exists already. We're looking to replace it because... (see below)
>
> Downside:
> - perl isn't very easy and userfriendly
I think that the downside is the fact that perl interpreters suck up
RAM, not the easiness factor. It's probably not significantly
easier/harder than lua, but it's big and clunky
Issac
Re: Dynamic configuration for the hackathon?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Jim Jagielski wrote:
>
> On Apr 1, 2008, at 9:36 AM, Jorge Schrauwen wrote:
>> Let me try and summarize this then:
>>
>> Problem:
>> The httpd configuration is to static for some users (e.g. large host
>> providers) they want to have a more dynamic system.
>
> IMO, based on feedback from people I've dealt with with my
> Covalent/SpringSource hat on, the biggest problem for these
> dynamic hosts is adding/changing/deleting SSL vhosts more
> than anything else :)
Actually, wearing my company's hat, our need is actually more for the
dynamic config (including vhosts if we could plug one in via a config
API) that can be modified at run-time (and not only after [graceful]
reloads).
Issac
Re: Dynamic configuration for the hackathon?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 1, 2008, at 9:36 AM, Jorge Schrauwen wrote:
> Let me try and summarize this then:
>
> Problem:
> The httpd configuration is to static for some users (e.g. large host
> providers) they want to have a more dynamic system.
IMO, based on feedback from people I've dealt with with my
Covalent/SpringSource hat on, the biggest problem for these
dynamic hosts is adding/changing/deleting SSL vhosts more
than anything else :)
Re: Dynamic configuration for the hackathon?
Posted by Jorge Schrauwen <jo...@gmail.com>.
Let me try and summarize this then:
Problem:
The httpd configuration is to static for some users (e.g. large host
providers) they want to have a more dynamic system.
Where they can configure things on a request basis and add vhosts and
such without restarting httpd.
Solutions propose:
- lua in the core or atleast in a module
- mod_perl
Downside:
- perl isn't very easy and userfriendly
- overhead of having this be re-evaluated a lot
- lue -> users to lazy to learn new language
I'm sure I missed a lot since I seem to be missing some older messages
so feel free to ignore this add to it or whatever.
--
~Jorge
Re: Dynamic configuration for the hackathon?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Graham Leggett wrote:
> Jim Jagielski wrote:
>
>> This reminds me: a serf BOF or session would, I think, go over
>> quite well :)
>
> A question that has been on my mind for a bit, is "what does serf intend
> to replace", and "why is it better?".
>
> The impression I have so far is that somehow what we have now is
> suboptimal, and that serf somehow does it better, but exactly what is
> suboptimal, and exactly how serf does it better has yet to be clarified.
Someone please consider offering a title/abstract/speaker/bio on a fast
paced introduction to the advantages of serf as a 15 minute FFT preso,
so that we can all understand the answers to Graham's questions.
fastfeather-2008-eu@apachecon.com - for either wed or thurs afternoon.
Re: Dynamic configuration for the hackathon?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 1, 2008, at 9:34 AM, Graham Leggett wrote:
> Jim Jagielski wrote:
>
>> This reminds me: a serf BOF or session would, I think, go over
>> quite well :)
>
> A question that has been on my mind for a bit, is "what does serf
> intend to replace", and "why is it better?".
>
> The impression I have so far is that somehow what we have now is
> suboptimal, and that serf somehow does it better, but exactly what
> is suboptimal, and exactly how serf does it better has yet to be
> clarified.
>
Basically, with serf it's easier to get away from the 1 request/response
cycle being tied to a specific thread/process. serf provides the async
aspects "for free" and abstracts it out for us.
Re: Dynamic configuration for the hackathon?
Posted by Graham Leggett <mi...@sharp.fm>.
Jim Jagielski wrote:
> This reminds me: a serf BOF or session would, I think, go over
> quite well :)
A question that has been on my mind for a bit, is "what does serf intend
to replace", and "why is it better?".
The impression I have so far is that somehow what we have now is
suboptimal, and that serf somehow does it better, but exactly what is
suboptimal, and exactly how serf does it better has yet to be clarified.
Regards,
Graham
--
Re: Dynamic configuration for the hackathon?
Posted by Jim Jagielski <ji...@jaguNET.com>.
IMO, we work best when we feel empowered to scratch our itches...
As we've also seen, sometimes all it takes is someone to create
a rough framework of an implementation for people to get excited
by it and jump right on in, adding, extending and tuning it.
This reminds me: a serf BOF or session would, I think, go over
quite well :)
Re: Dynamic configuration for the hackathon?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 1, 2008, at 10:32 AM, Matthew M. Burke wrote:
> Graham Leggett wrote:
>>
>> The trouble is, if I want to solve problem A ("configure the
>> server"), and I find out that before I can solve problem A
>> ("configure the server") I need to first solve problem B ("learn a
>> new language"), that is a big incentive to just ignore the new
>> server and stick with httpd v2.
>>
>> It makes no difference in the world how "easy" Lua is to learn, "no
>> learning required" will always beat "easy to learn" hands down
>> every single time.
>>
> That's just marketing! Configuring the server is not a "no learning
> required" activity, particularly if you are using mod_rewrite!
>
> Matt
>
Graham's point is, I think, that for most setups, although ugly, the
config does not require a lot of thought. Compare, for example,
a "typical" Apache config to sendmail's sendmail.cf file :)
Re: Dynamic configuration for the hackathon?
Posted by "Matthew M. Burke" <mm...@gwu.edu>.
Issac Goldstand wrote:
>
>
> We're not talking about fresh users, we're talking about existing
> users. Fresh users have to deal with one learning curve or another
> anyway.
I'm not talking about fresh users either.
Matt
Re: Dynamic configuration for the hackathon?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Matthew M. Burke wrote:
> Graham Leggett wrote:
>>
>> The trouble is, if I want to solve problem A ("configure the server"),
>> and I find out that before I can solve problem A ("configure the
>> server") I need to first solve problem B ("learn a new language"),
>> that is a big incentive to just ignore the new server and stick with
>> httpd v2.
>>
>> It makes no difference in the world how "easy" Lua is to learn, "no
>> learning required" will always beat "easy to learn" hands down every
>> single time.
>>
> That's just marketing! Configuring the server is not a "no learning
> required" activity, particularly if you are using mod_rewrite!
>
We're not talking about fresh users, we're talking about existing users.
Fresh users have to deal with one learning curve or another anyway.
Issac
Re: Dynamic configuration for the hackathon?
Posted by "Matthew M. Burke" <mm...@gwu.edu>.
Graham Leggett wrote:
>
> The trouble is, if I want to solve problem A ("configure the server"),
> and I find out that before I can solve problem A ("configure the
> server") I need to first solve problem B ("learn a new language"),
> that is a big incentive to just ignore the new server and stick with
> httpd v2.
>
> It makes no difference in the world how "easy" Lua is to learn, "no
> learning required" will always beat "easy to learn" hands down every
> single time.
>
That's just marketing! Configuring the server is not a "no learning
required" activity, particularly if you are using mod_rewrite!
Matt
Re: Dynamic configuration for the hackathon?
Posted by Graham Leggett <mi...@sharp.fm>.
Akins, Brian wrote:
> My opinion (which is worthless, I know) is to pick one way and do it. Lua
> is easy to learn and satisfies most (all?) of our requirements. And if
> Brian M. and I can learn it, anyone can ;)
The trouble is, if I want to solve problem A ("configure the server"),
and I find out that before I can solve problem A ("configure the
server") I need to first solve problem B ("learn a new language"), that
is a big incentive to just ignore the new server and stick with httpd v2.
It makes no difference in the world how "easy" Lua is to learn, "no
learning required" will always beat "easy to learn" hands down every
single time.
The Apache config already supports the concepts of a "global" config,
and a per-request config (.htaccess), these basic things could easily
form the building blocks of a pluggable config mechanism, in whatever
language you like.
Regards,
Graham
--
Re: Dynamic configuration for the hackathon?
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/1/08 5:35 AM, "Issac Goldstand" <ma...@beamartyr.net> wrote:
> I don't think we're even talking about on-the-fly stuff for the "Lua"
> parser engine, so Perl can do everything that Lua can.
I am.
The biggest problems I have with current system are:
-Every module does things differently
-No real per-request configuration. Some modules use env to do some of
this.
-I have to write a good bit of code before a module is configurable. (I'm
lazy. Very lazy.)
If we do what niq suggests (which, if we stick with current config system is
fine) is that it just adds another layer on top of all the existing issues.
With lua, for example you could make modules Lua modules... Maybe could do
same in perl??
My opinion (which is worthless, I know) is to pick one way and do it. Lua
is easy to learn and satisfies most (all?) of our requirements. And if
Brian M. and I can learn it, anyone can ;)
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: Dynamic configuration for the hackathon?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Torsten Foertsch wrote:
> On Tue 01 Apr 2008, Paul Querna wrote:
>> William A. Rowe, Jr. wrote:
>>> -0.99 - agreed. Perl is perfectly happy having <perl> blocks as modular
>>> behaviors... I've noticed a trend in the last few years of building on
>>> the core (and folks rightfully accused me of growing mod_proxy core when
>>> new directives are rightfully part of mod_proxy_{whatever}).
>> Yes, but the root of the problem even with <perl> blocks is that they
>> have almost no way to change the behavior of existing modules -- like
>> you can via configuration -- and instead for the most part, they
>> reimplment entire C modules in Perl, or any other language, rather than
>> binding to the configuration, and change that based on some other inputs.
>
> I disagree. In the mod_perl API you can almost entirely configure a single
> request. You can hook maptostorage and add there directives for other modules
> via $r->add_config. Anything that can be configured in .htaccess or
> <Location> can be done that way as well. One can even change DocumentRoot
> (prefork-only) for a single request. The PerlMapToStorageHandler can then
> decide whether to skip the standard maptostorage (directory walk and file
> walk) or not. It would be good for such a perl-configured request to be able
> to skip the location-walk that follows maptostorage. But if the admin wants
> to do that he can simply avoid <location> blocks.
>
> You cannot add virtual servers on the fly or redirect error_log. But I don't
> expect that to become feasible in the new config language since those are
> things that are done at server startup.
>
I don't think we're even talking about on-the-fly stuff for the "Lua"
parser engine, so Perl can do everything that Lua can. As people have
mentioned, though, Perl is bloated (but +1 for mp2.1 to include plugs
for this new config API :))
>> Then the existing configuration file, a new lua system, or anything
>> else, could be written in terms of that, rather than the current system
>> where each language reinvents the modules it wants to control.
>
> I agree that a configuration language like lua is good but it doesn't
> necessarily have to be in core. It can be a module as mod_perl shows.
I think if we take Paul's idea of a new pluggable API, we'll have a lot
of happy people. We can have a lua implementation, a perl
implementation, and IMHO we should retain some C implementation to the
crappy config that people (users) have now and are used to working with
(and bear in mind that there are STILL folks out there in 1.3-land
because of what we did to the httpd-2 config).
It would make everyone happy by having a C implementation that can be
used immediately without any new dependencies (and looks just like the
existing engine does), a Lua implementation which can come
out-of-the-box with mod_wombat (and we can even make that the "ASF
recommended" approach effective immediately as long as we keep
everything compatible at least until httpd-3 is ready), and mod_perl
(and friends) can provide other interfaces.
My EUR 0.02,
Issac
Re: Dynamic configuration for the hackathon?
Posted by Torsten Foertsch <to...@gmx.net>.
On Tue 01 Apr 2008, Paul Querna wrote:
> William A. Rowe, Jr. wrote:
> > -0.99 - agreed. Perl is perfectly happy having <perl> blocks as modular
> > behaviors... I've noticed a trend in the last few years of building on
> > the core (and folks rightfully accused me of growing mod_proxy core when
> > new directives are rightfully part of mod_proxy_{whatever}).
>
> Yes, but the root of the problem even with <perl> blocks is that they
> have almost no way to change the behavior of existing modules -- like
> you can via configuration -- and instead for the most part, they
> reimplment entire C modules in Perl, or any other language, rather than
> binding to the configuration, and change that based on some other inputs.
I disagree. In the mod_perl API you can almost entirely configure a single
request. You can hook maptostorage and add there directives for other modules
via $r->add_config. Anything that can be configured in .htaccess or
<Location> can be done that way as well. One can even change DocumentRoot
(prefork-only) for a single request. The PerlMapToStorageHandler can then
decide whether to skip the standard maptostorage (directory walk and file
walk) or not. It would be good for such a perl-configured request to be able
to skip the location-walk that follows maptostorage. But if the admin wants
to do that he can simply avoid <location> blocks.
You cannot add virtual servers on the fly or redirect error_log. But I don't
expect that to become feasible in the new config language since those are
things that are done at server startup.
> Then the existing configuration file, a new lua system, or anything
> else, could be written in terms of that, rather than the current system
> where each language reinvents the modules it wants to control.
I agree that a configuration language like lua is good but it doesn't
necessarily have to be in core. It can be a module as mod_perl shows.
Torsten
Re: Dynamic configuration for the hackathon?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 1, 2008, at 2:17 AM, Justin Erenkrantz wrote:
> On Mon, Mar 31, 2008 at 7:41 PM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> wrote:
>> I sympathize, but this doesn't reflect the addition of <lua>
>> blocks...
>> those blocks can be trivially implemented as a loadable module ;-)
>
> As I grok it, the point would be throw out our ridiculous config
> syntax entirely (or at best write a compatibility module or a
> converter to the new format) and expose a real config API (hello
> providers! *chuckle*) and then build a pure LUA-based config format on
> top of that.
>
> I'd be definitely curious to see what would come of that - 'cuz really
> it can't be much worse than the garbage we're stuck with now. --
> justin
>
Agreed... historically, of course, that alone has not be
reason enough. I recall many many "discussions", esp with Dean,
about the overhead of folding such a "complex" parser into httpd
compared to having that done externally (m4 anyone? :) ) and
out of process...
Re: Dynamic configuration for the hackathon?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Mar 31, 2008 at 7:41 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> I sympathize, but this doesn't reflect the addition of <lua> blocks...
> those blocks can be trivially implemented as a loadable module ;-)
As I grok it, the point would be throw out our ridiculous config
syntax entirely (or at best write a compatibility module or a
converter to the new format) and expose a real config API (hello
providers! *chuckle*) and then build a pure LUA-based config format on
top of that.
I'd be definitely curious to see what would come of that - 'cuz really
it can't be much worse than the garbage we're stuck with now. --
justin
Re: Dynamic configuration for the hackathon?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
>
> Then the existing configuration file, a new lua system, or anything
> else, could be written in terms of that, rather than the current system
> where each language reinvents the modules it wants to control.
I sympathize, but this doesn't reflect the addition of <lua> blocks...
those blocks can be trivially implemented as a loadable module ;-)
Re: Dynamic configuration for the hackathon?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Paul Querna wrote:
> William A. Rowe, Jr. wrote:
>> Issac Goldstand wrote:
>>>
>>> Paul Querna wrote:
>>>> Akins, Brian wrote:
>>>>> On 3/26/08 9:06 AM, "Nick Kew" <ni...@webthing.com> wrote:
>>>>>
>>>>>> There seems to be a demand for dynamic per-request configuration,
>>>>>> as evidenced by the number of users hacking it with mod_rewrite,
>>>>>> and the other very limited tools available. Modern mod_rewrite
>>>>>> usage commonly looks like programming, but it's not designed as
>>>>>> a programming language. Result: confused and frustrated users.
>>>>>
>>>>>
>>>>> This is what I had in mind when I suggested having <Lua> blocks of
>>>>> code. No
>>>>> need to invent a new language when a perfectly fine one exists...
>>>>>
>>>>
>>>> +1, and embed Lua in the core, and a dozen problems just like this
>>>> are solved.
>>>
>>> -0.5 PLEASE not in the core. Make mod_wombat a standard module and
>>> part of the default moduleset, whatever, but let's not make more core
>>> dependencies, please?!?
>>
>> -0.99 - agreed. Perl is perfectly happy having <perl> blocks as modular
>> behaviors... I've noticed a trend in the last few years of building on
>> the
>> core (and folks rightfully accused me of growing mod_proxy core when new
>> directives are rightfully part of mod_proxy_{whatever}).
>
> Yes, but the root of the problem even with <perl> blocks is that they
> have almost no way to change the behavior of existing modules -- like
> you can via configuration -- and instead for the most part, they
> reimplment entire C modules in Perl, or any other language, rather than
> binding to the configuration, and change that based on some other inputs.
>
> The few that can change behaviors, ie via ENV vars, are special cases in
> every modules case, and do not make a difference in the larger picture.
Not completely true. mod_perl provides several ways to bind to the
configuration. Consider this bit of Perl magic - this is some mp1 code,
running in Perl-land, not in a <Perl> block, though it could as easily
be run there...
package Apache::ReadConfig;
no strict;
$Location{$UploadScript} = {
Options => '+ExecCGI',
PerlHeaderParserHandler => $namespace."::upload_jit_handler",
};
$Location{$UploadMeter} = {
Options => '+ExecCGI',
PerlHeaderParserHandler => $namespace."::meter_jit_handler",
};
$Location{$UploadForm} = {
Options => '+ExecCGI',
PerlHeaderParserHandler => $namespace."::form_jit_handler",
};
Granted, you're still limited to the underlying config parser, so I'm
not arguing with the new config API idea (at least as I understood it
yesterday), but this should be treated as a pluggable config engine
which everyone can access; not as a switch from one config parser to
another.
Issac
Re: Dynamic configuration for the hackathon?
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> Issac Goldstand wrote:
>>
>> Paul Querna wrote:
>>> Akins, Brian wrote:
>>>> On 3/26/08 9:06 AM, "Nick Kew" <ni...@webthing.com> wrote:
>>>>
>>>>> There seems to be a demand for dynamic per-request configuration,
>>>>> as evidenced by the number of users hacking it with mod_rewrite,
>>>>> and the other very limited tools available. Modern mod_rewrite
>>>>> usage commonly looks like programming, but it's not designed as
>>>>> a programming language. Result: confused and frustrated users.
>>>>
>>>>
>>>> This is what I had in mind when I suggested having <Lua> blocks of
>>>> code. No
>>>> need to invent a new language when a perfectly fine one exists...
>>>>
>>>
>>> +1, and embed Lua in the core, and a dozen problems just like this
>>> are solved.
>>
>> -0.5 PLEASE not in the core. Make mod_wombat a standard module and
>> part of the default moduleset, whatever, but let's not make more core
>> dependencies, please?!?
>
> -0.99 - agreed. Perl is perfectly happy having <perl> blocks as modular
> behaviors... I've noticed a trend in the last few years of building on the
> core (and folks rightfully accused me of growing mod_proxy core when new
> directives are rightfully part of mod_proxy_{whatever}).
Yes, but the root of the problem even with <perl> blocks is that they
have almost no way to change the behavior of existing modules -- like
you can via configuration -- and instead for the most part, they
reimplment entire C modules in Perl, or any other language, rather than
binding to the configuration, and change that based on some other inputs.
The few that can change behaviors, ie via ENV vars, are special cases in
every modules case, and do not make a difference in the larger picture.
The core of what I want is a better configuration API.
Then the existing configuration file, a new lua system, or anything
else, could be written in terms of that, rather than the current system
where each language reinvents the modules it wants to control.
-Paul
Re: Dynamic configuration for the hackathon?
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Jim Jagielski wrote:
> I'd prefer optimum runtime and let that drive how it gets exposed to
> the admin, rather than the reverse... And then we can see if that
> pain is worth it :)
+1 to this as a guiding principle.
I know our administrators would, above all else, like a standard
way to build up configuration files from templates. Perhaps that could
be mod_macro packaged in the main distribution, or some kind of
"configulator" utility, or yet something else.
Dynamic (re)configuration issues are a lesser concern for them, I
think; it would be great if whatever is implemented could be largely
optional so it can be loaded only if necessary. Good luck at the
hackathon!
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: Dynamic configuration for the hackathon?
Posted by Jim Jagielski <ji...@jaguNET.com>.
Can we 1st determine exactly what pain-point we're trying to solve here?
Or, at least, prioritize them?
It seems to me that if the main issue is runtime re-configuration
during the request/response phases, then that really forces us into
something which must be very lean, mean and FAST. By extension, this
also provides to us a way to really clean up and standardize our
current config mess.
If however, our focus would be to make our config files cleaner and
prettier, then I fear that by the time that trickles down to
how that interacts with the actual runtime processing, we'll get
nasty performance.
I'd prefer optimum runtime and let that drive how it gets exposed to
the admin, rather than the reverse... And then we can see if that
pain is worth it :)
Re: Dynamic configuration for the hackathon?
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:
>> -0.5 PLEASE not in the core. Make mod_wombat a standard module and
>> part of the default moduleset, whatever, but let's not make more core
>> dependencies, please?!?
>
> -0.99 - agreed. Perl is perfectly happy having <perl> blocks as modular
> behaviors... I've noticed a trend in the last few years of building on the
> core (and folks rightfully accused me of growing mod_proxy core when new
> directives are rightfully part of mod_proxy_{whatever}).
>
> Let's focus on keeping it in useful pieces, even if they are built by
> default.
-0.99 - agree with wrowe.
I looked at the option of supporting different configuration providers a
while back, I was researching the idea that configuration could be
stored in LDAP instead of flat files, and it seemed pretty
straightforward (didn't have time to explore further).
What I did find is that it is quite possible to support pluggable
configuration options, it isn't difficult: your configuration module
must somehow render config lines which are pumped into the core. How
those lines come into existence, whether sourced from flat file, rows in
a database, or rendered by a programming language, is up to you.
One further thing PLEASE not the default. I don't have the time in my
day to learn a whole programming language just to configure my webserver.
The problem that needs solving is to find an acceptable tradeoff between
allowing the mod_rewrite fans to do complex stuff, while at the same
time letting us mere mortals do the simple stuff as well without any
drama. Please don't lose sight of that.
Regards,
Graham
--