Re: apache2: clearing the air [please read]
Joey Hess wrote:
>
> Erik Steffl wrote:
> > in the end, it does not matter whether it's administrator who creates
> > virtual hosts or debian - if they are against debian policy (or do not
> > conform to standard file system layout) it's bad (think about it, we
> > don't have policy for policy's sake, we have it for a reason).
>
> That's really not the case. The administrator of a system is free and
> welcome to do anything they like to it, whether it conforms with policy
> or not. They don't have to even know anything about policy. Our task is
> just to provide a system that does reasonable things by default and that
> doesn't get in their way. We have policy to make debian a
> self-consistent, well-engineered system, not to tie sysadmin's hands.
the goals of both policy and administrator are bascially the same. if
the policy were perfect, there would be (almost) no need for
administrator.
whether you create a policy or you actually administer the system,
your requirements are basically the same. Of course, the policy is a lot
more abstract, has to be more flexible etc.
> All debian-admin maintained machines have a /org/ directory in the
> root. This "violates" FHS and debian policy. This does not mean that
> debian-admin don't know what they're doing or are doing something bad.
>
> http://www.debian.org/doc does not point to the /usr/doc directory, even
> though policy says it should. This is not wrong; there is a more
> important thing to use /doc for on that we site.
there are exceptions to all rules (even to this one:-)
> I have my web document root in /home/pub for my main system, and have a
> very oddly configured virtual host. My system is still 100% policy
> compliant. And I'm not going to change my setup just because debian
> comes up with some all-encompassing vhost setup.
but the question is not whether it's policy compliant, the question is
whether it's good design... the policy is just the formalization of what
people consider good (enough) design...
my point in previous discussion: if we don't want to do something
during installation of a program because it's not compliant but expect
people to do it manually then we didn't solve anything, yes, the systems
will be policy compliant but the end result is the same... blame shifts
but that's all...
btw "I'm not going to change my setup just because debian comes..." is
not a valid argument - it can be used against (almost?) ANYTHING in
policy.
> > there has to be a way to create virtual hosts - if debian policy
> > currently does not allow it (does not mention virtual hosts (and as
> > other pointed out it's not only about web servers)) the policy has got
> > to change (I don't say that what apache2 team did is the best solution).
>
> Policy does not have to mention every niggly little thing.
IMO the virtual hosts for apache are quite essential... and more, the
configuration for n hosts is able to easily accomodate the ones that
only have one host, at no extra cost [the only extra cost is during
design of the system].
the question is, how far it should be taken - should the virtual host
be completely separate 'machine' (with its own log, cgi and other
directories (possibly having it's own installation of apache which
changes everything:-), possibbly suitable for chrooting or is it better
to have the virtual machine spread all over the place (log in /var/log,
cgi in /usr/lib etc.).
It might be best to have both scenarios available and let system
administrator choose the one that will be used.
e.g. when one person/team manages the machine inlcuding all apache
virtual machines then it makes more sense to have virtual host spread
(all log are in /var/log etc.)
however, when the virtual hosts are administered by different
individuals, it makes more sense to have self-contained directories with
everything needed under one directory.
this might be generalized to have recursive virtual hosts in one
filesystem, not only for web servers but for other purposes as well (I
guess in general the depth would be just one level, i.e. the virtual
hosts would not contain further virtual hosts).
erik
Reply to: