dynamic virtual hosting

[Tony Finch <do...@dotat.at>]

While updating some old docs I rediscovered this bit of speculation
that I wrote in January. I haven't looked very closely at the new
module API yet, but I'm wondering whether its increased flexibility
would make something like this more elegant, or perhaps its a
candidate for EAPI abstraction. I also haven't thought much about
whether modules would get fatally confused if all the configuration
things don't happen at once and in the context of the parent.

> Ideally we'd like our virtual hosting database to be our company-wide
> centralised configuration database so that we can dispense with grotty
> perl management scripts kludged together with some string and a bit of
> glue. The requirements are rather stringent, however: the database
> must be able to answer hundreds of queries per second each within a
> few milliseconds, and scale to hundreds of thousands of records. Can
> anything do this?
> 
> In the completely general case it would be cool to be able to store
> arbitrary configuration directives in the database so that we could
> provide different levels of service: e.g. AllowOverride if the
> customer can use .htaccess files, or Options Includes if they can use
> SSI, etc. Perhaps Apache could build a traditional internal virtual
> host configuration on the fly from the database lookup and use that as
> a cache for future requests, relying on the MaxRequestsPerChild
> setting to keep the cache fresh.
> 
> A possible implementation strategy is to add another round to the
> module interface, and alter the virtual hosting code so that when an
> incoming request does not match an existing virtual host configuration
> the modules are given a chance to create one.
> 
> On the other hand, perhaps I'm just speculating wildly.

Tony.
-- 
fanf@demon.net -- dot it at

File reading abstraction (Was: dynamic virtual hosting)

[Henrik Vendelbo <hv...@bluprints.com>]

----- Original Message ----- 
From: Graham Leggett <mi...@sharp.fm>
To: <ne...@apache.org>
Sent: Wednesday, October 13, 1999 2:37 PM
Subject: Re: dynamic virtual hosting


> Perhaps abstracting the process of reading the config file from a file
> on disk could be a solution, so that instead of the config being sucked
> in from httpd.conf, it could be sucked in from an LDAP server (my
> personal favourite) or something else.

That would play well into another discussion I recently had on the WebDav list. Being able to place the web files on a filesystem not accessible through standard I/O would be beneficial in a number of situations.

Re: dynamic virtual hosting

[Dirk-Willem van Gulik <di...@webweaving.org>]

On Wed, 13 Oct 1999, Graham Leggett wrote:

> Or, perhaps an extension on "VirtualHost", where you would have a config
> like this:
> 
> <Virtualhost (some LDAP search filter)>
>   DefaultOptionForAllServers foo
>   SomeOtherDefaultOption bar
> </VirtualHost>
> 
> which pulls objects from an LDAP server based on the search filter, each
> object containing the config for that server. Defaults for all servers
> could be defined in the container as shown.

Actually I recently did a small hack for a customer; which I guess could
go into apache which simply allows a 'URL' specifier anywhere in the
config file which then pulls in the required part. 

We do the same for the log files going out. It is imple http:, ftp:
(because it is in mod_proxy already) and a raw socket: Note that it was
done badly; so during init you fetch twice, etc, etc.

But I figured that this would be of fairly limited use. But seeing you two
talk, would you actually see things like #include http://cnfsrv/cnf.pl?12
address a large enough slice of the problem to be worth for proposing
including in apache ?

Dw

Re: dynamic virtual hosting

[Graham Leggett <mi...@sharp.fm>]

Tony Finch wrote:

> While updating some old docs I rediscovered this bit of speculation
> that I wrote in January. I haven't looked very closely at the new
> module API yet, but I'm wondering whether its increased flexibility
> would make something like this more elegant, or perhaps its a
> candidate for EAPI abstraction. I also haven't thought much about
> whether modules would get fatally confused if all the configuration
> things don't happen at once and in the context of the parent.
> 
> > Ideally we'd like our virtual hosting database to be our company-wide
> > centralised configuration database so that we can dispense with grotty
> > perl management scripts kludged together with some string and a bit of
> > glue. The requirements are rather stringent, however: the database
> > must be able to answer hundreds of queries per second each within a
> > few milliseconds, and scale to hundreds of thousands of records. Can
> > anything do this?

Perhaps abstracting the process of reading the config file from a file
on disk could be a solution, so that instead of the config being sucked
in from httpd.conf, it could be sucked in from an LDAP server (my
personal favourite) or something else.

More usefully configuration could be included via a variation on the
Include directive that would pull in information it needed from wherever
and included in a "global configuration" which would define in addition
to other things where the config came from.

Or, perhaps an extension on "VirtualHost", where you would have a config
like this:

<Virtualhost (some LDAP search filter)>
  DefaultOptionForAllServers foo
  SomeOtherDefaultOption bar
</VirtualHost>

which pulls objects from an LDAP server based on the search filter, each
object containing the config for that server. Defaults for all servers
could be defined in the container as shown.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight...