perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Prime <adam.pr...@utoronto.ca>
Subject Re: Configuring virtual hosts on the fly
Date Mon, 12 Oct 2009 16:57:50 GMT
Scott Gifford wrote:
> Hello,
> 
> I'm working on an Apache configuration for a cluster of machines
> serving a variety of virtual hosts.
> 
> New virtual hosts are provisioned by a Web application, and all
> information needed to set up the virtual hosts is in a database table.
> I would like my Apache to set up the virtual hosts on the fly based on
> information in the tables.
> 
> I have seen examples for generating the virtual hosts configuration
> from a database when Apache starts.  That leaves me with the problem
> of how the unprivileged Web application doing the provisioning can
> reliably trigger a reload across an entire cluster, and also what to
> do if something goes wrong so I don't end up with a whole cluster of
> dead Web servers.
> 
> It seems much cleaner to me to let Apache look up the information for
> a virtual host as it is needed.  Conceptually, when each request comes
> in, I would like Apache to look at the Host: header, build a temporary
> virtual host entry from that, and use it to service the request.  I
> will use caching to make it reasonably fast.  Then the provisioning
> script just writes to the database table and is done, and I can handle
> any errors on a per-request basis without Apache failing to start.
> 
> I see some hooks in PerlTransHandler and PerlMapToStorageHandler that
> seem like they can almost do what I want, but I don't see how to set
> other virtual host parameters, like ServerAdmin, UseCanonicalName,
> etc.
> 
> I'm just starting to work on this, and I thought I would see if
> anybody had tried anything similar before and had some suggestions for
> what to do, or what not to do.
> 
> Thanks!

I did some cursory investigation into something sort of like this, at
least the idea that the application would be able to create new virtual
hosts, and that those vhosts should start 'working' (for some definition
of working) immediately.

The approach that I had intended to take with regards to getting the
name based vhosts to work immediately (without a restart) was to have a
default virtual host that would detect requests that were coming in for
vhosts that we should be able to handle, and then setting up the handler
stack for that request using push_handlers in an init handler.  There
are some problems with this approach (segmenting logs for one), but the
idea for me was to get the thing to work right away, and if it took
until the next restart to get the vhost actually configured as a vhost
properly, that wasn't a huge deal.

Not sure if that's any help or not, but...

Adam

Mime
View raw message