[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apache2: clearing the air [please read]

On Thu, Oct 11, 2001 at 10:56:32PM +1000, Hamish Moffatt wrote:
> On Thu, Oct 11, 2001 at 10:39:21PM +1000, Daniel Stone wrote:
> > On Thu, Oct 11, 2001 at 02:34:40PM +0200, Wichert Akkerman wrote:
> > > Putting CGI and logfiles in /var/www is also a clear violation of the
> > > FHS.
> > 
> > IIRC the real FHS doesn't even mention /var/www. But that's IIRC, which
> > is currently a little hazy.
> That's not the point: binaries (cgi-bin) shouldn't be in /var,
> and logs should be in /var/log, always, with no exceptions.

Not quite true. Binaries are expected to be static as in not changing.
The main aim of that requirement is to permit /usr to be readonly, IIRC.

/var is for "things that change". CGI scripts fit that description. So,
they should be in both /usr and /var...

CGI scripts *will* be changing, and not always under the control of the
admin. In fact, having /usr mounted ro would likely make such a situation
much more secure.

Back to the other half of this thread, I initially agreed with Daniel
about the virtual hosting locations. But Wichert's made some good points,
which I am inclined to agree with. The upshot of which is that it would
make sense to at least discuss radically changing the way Debian deals with 
such things - there are potentially many packages that could easily help
admins doing vhosting, if only Debian had a policy on how + where to put

Should it all go in one place (similar to Wichert's /vhost arrangement) or
separately for www, mail etc.?

You might say that "it's up to the admin". It all is, in the end. But at
the moment, the admin is *always* forced to do a bunch of work that might
not be necessary if we came up with a reasonable, flexible, standard way
of dealing with vhosts.

Then the admin would only have to do a bunch of work if they wanted it to be
radically different.

I really think it's worth sitting down and thinking about (or flaming the
sh*t out of each other to arrive at) a good answer to this.



Nick Phillips -- nwp@lemon-computing.com
It was all so different before everything changed.

Reply to: