Re: [PHP] Placement of PHP programs?
On Sat, Sep 07, 2002 at 11:23:37AM +1000, Matthew Palmer wrote:
> This is something which has had a bit of debate - whether /var/www is for
> the admin or the distribution. I'm inclined to go with your view - that
> it's for the admin, but I can't find any documentation which codifies that
> view.
We don't have a sane policy on this, AFAICT. To date, packages (including
Apache itself in particular) have done pretty much whatever they like with
/var/www, to the extent that it's not been a useful/useable location for
an admin to use as a real webroot. There was some discussion about how best
to deal with this when Thom & (I think) Daniel Stone first started work
on apache 2, but I think the conclusion was 'OK, go away and work on it'.
It does appear that packages have been gradually shying away from putting
stuff into /var/www directly, in favour of tactics such as you mentioned
(sticking everything they need in /usr/share somewhere and providing and
apache config-chunk to be included by your httpd.conf as appropriate. This
is a Good Thing, but I don't think we've arrived yet.
I haven't looked at apache 2 yet, but it seems to me that it might be a
good idea to generalise this discussion into 'how do we handle packaging
web applications' and come up with a good overall solution rather than
one just for PHP, which could be rendered obsolete when we finally do
come up with an overall answer.
I'd note here that a common problem with packages of web applications
seems to be "OK, I've installed it, now where the hell is it?"; debconf
notes and all sorts are (mis)used to tell the admin where to find their
new software. Then there's the security question; if a web-based app is
automatically configured to run (e.g. with CGI scripts is /usr/lib/cgi-bin),
it's great that it "just works", but likely to be pisspoor that suddenly
the whole world can see, for example, all your CVS repositories (I'm not
suggesting that this actually does happen with either cvsweb or viewcvs,
but it's an example of what could happen).
It might make more sense if we were to configure webservers by default to
serve standard content *only* to localhost, and set things up to allow
packages to create a <packagename> subdirectory under /var/www with any
static html pages that would provide a starting point for the admin's use
or further configuration of the package.
Webserver packages could also optionally provide an interface for such
application packages to add their extra config -- for example apache
could provide a directory into which apps could dump config fragments
to be included into the default server setup, and a script to regenerate
the config to include them.
This would make things nice and simple for the admin setting up such packages
(they would 'just work' for localhost) to find where and how they've been
installed, and evaluate them, before getting to grips with configuring his
'real' servers to make them available more widely.
The big snag is that /var/www is rendered pretty much unusable by the
legacy of the last several years, and the use to which admins may currently
be putting it.
I'd suggest we leave /var/www to admins to deal with as they will, and
move the default setup to somewhere else; possibly stick the default webroot(s)
in /usr/share, even.
At any rate, it's something that we should certainly sort out. I guess now I
should go & install apache2 and see whether and how much that has improved
things...
Cheers,
Nick
--
Nick Phillips -- nwp@lemon-computing.com
Go to a movie tonight. Darkness becomes you.
Reply to: