Re: [gentoo-dev] [GLEP] Web Application Installation. Plotting a VHOST config tool.

[Stuart Herbert]

On Wednesday 06 August 2003 5:37 am, Robin H.Johnson wrote:
> Ok, so if -vhosts, we install to /usr/share/webapp/(whatever) and
> automatically run the webapp-config tool ?

Yeah, I think that'd be good, especially if we bring in the move to 
/var/www/localhost as the new default location for -vhosts systems.

> if +vhosts, we install to /usr/share/webapp/(whatever) and the
> administrator is left to run the rest himself.

Definitely.

> As part of the planning, and a good first step
> I'm plotting out a config tool for adding vhosts. All comments welcome
> as this is intended to be a good outline of what the tool must do etc
> before I write it (borrowing heavily from my exist custom scripts for
> the purpose).

Off the top of my head, here's a partial wish-list:

* add new vhost
* destroy existing vhost
* suspend vhost, but do not destroy
* add <webapp> to <location> inside <vhost>
* upgrade <webapp> at <location> inside <vhost>
* remove <webapp> at <location> inside <vhost>

The config tools are going to need to emulate CONFIG_PROTECT behaviour; either 
that, or we'll need some improvements to be made to Portage.

For now, I suggest we treat database creation/upgrades/etc as out-of-scope, 
unless someone wishes to step forth from the shadows with a plan for this?

> Stuart: once before you asked why I didn't use dynamic vhosts.
> Two reasons behind it. Firstly, I want seperate log files for each
> vhost,

Excellent point.

> and secondly I have a lot of apache configuration directives that
> vary per server (funky mod_rewrite stuff mainly to make variable
> handling in php interesting).

Grin.

> Based on this, I strongly believe that
> 'simple' vhosts are the best way to go in general.

Then let's do it.

> I feel the name 'htdocs' belies the meaning of the directory more
> accurately, but I'm looking for input on that item.

+1 for htdocs.

> Rough outline of tool:
>
> vhost-config must do three things:
> - creates directories (copies a skeleton directory for the most part).
> - create apache vhost config files.
> - HUP apache so it reads in the new config without stopping.
>
> Proposed rough usage:
> vhost-config [opts] fully.qualified-domain.name

[snip]

The options look good.  The only additional behaviour I'd suggest is to create 
symlinks from ~<user>/vhosts/<FQDM> to /var/www/<FQDM>, to make it easier for 
people with shell accounts on the box to find their own domains.

How about making /var/www/<FQDM> chmod'd 750 by default, and owned by the 
apache group by default?  On shared boxes with shell accounts, this'd mean 
that apache can serve the files, but other shell accounts can't take a peak.

> /etc/vhost-skel/ might contain:
> htdocs/ = maybe a simple index.html ?

Yes.  I'd go further and make it a symlink to a default index.html page, so 
that changes to a master copy are automatically picked up for domains that 
have been created but left unused.

> conf/ = [treated specially] ${server}.conf that is used for creating the
> initial config, templates of some sort (I'm leaning to M4 as all my
> existing stuff is in it, and it's good for templating like this).

/me hates m4 ;-)

What are you going to write the tools in? Python, bash, PHP, or something 
else?

> After vhost-config has generated all of the nessicary stuff, it should
> HUP the apache server if everything is in order.

Yup.

> There is one check that is outside the scope of the tool, namely the
> existance of DNS for the specified hostname. If the admin creates a
> vhost that does not yet have DNS or name resolution relative to the
> system, we should display a warning.

I like this.  Maybe the default behaviour could be to throw an error, and 
supply a '--force' option to downgrade to a warning?

> I'd repeat again for good measure, this email is strongly based off the
> present capabilites of my private vhost setup scripts, plus the features
> I as a developer, sysadmin and user want in a new revision. However I
> strongly feel that more input is needed as well.

Well, you've got mine now ;-)

Webapps aren't the only type of application that can take advantage of a 
vhosts solution.  Games servers such as the Half-Life Dedicated Server (HLDS) 
can also benefit from being deployed into a vhosts-type scenario.

Obviously, there are important differences, which means that the exact same 
tool can't be used to manage both.  But, if we can identify and extract out 
common elements so that they can be re-used by different scripts, that might 
help validate both the design and the implementation.

Take care,
Stu
-- 
Stuart Herbert                                              stuart@g.o
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--