On Wed, Jun 27, 2007 at 09:06:07PM +0200, Nicolas Mailhot wrote:
Le mercredi 27 juin 2007 à 20:52 +0200, Axel Thimm a écrit :
> On Wed, Jun 27, 2007 at 08:41:43PM +0200, Nicolas Mailhot wrote:
> > You have file resources, and you have local network policies (which may
> > even be dynamic with dhcp avahi & friends). They never map 1:1. Forcing
> > file layout to reflect domain layout is an exercise in futility.
> I agree, which is why you can't this all happen under /srv.
No. That means you partition /srv in an rpm-controlled part, and a
free-for-all part. This way you can have sane pre-configured defaults,
and people can do something else if they really want to.
The current habit of shunning /srv at all costs results in:
— defaults not being pre-configured & installed because the sane place
to put them is blacklisted
Not really, the reason for not having defaults is that by definition
the contents cannot be provided and cannot be open by default. We're
talking about daemons accessing local data. :)
— or defaults that can not serve as examples (because their layout
has no relation with the /srv/ users are supposed to use),
Yes, but which one of the three popular /srv layouts are users
supposed to use?
confuse scripts (again because of the layout mismatch), confuse
security policies, etc
If you don't know what data will be under /srv and how the sysadmin
will be managing it you can' provide anything of this kind. And you
can't enforce a model that works for half the users and not for the
You can have a /srv/default and a /srv/local, or a /srv and
/local/srv, or whatever but two totally different policies is just
shooting ourselves in the foot.
/srv is already in various FHS-compliant use on thousands of
sites. You can't touch it really. And if you were to create a
/vendor-default-and-examples/srv then you can use /var/lib/foo as
In fact many "data carrying" applications like name servers, MTAs
etc. use /var in the FHS, although technically they would have to move
that content to /srv, by /srv's definition. And in fact² in a
multi-domain setup one is often forced to do so to separate
instances. This is also important in a cluster/gfs setup, where member
A could be serving domain X and Y, or only one, or none. So the
daemons need to have separate fs paths.
On the other hand a multi-homed system may want to keep it all
virtualized instead of clustered, so with the choice comes the need
for different layouts and we can't dictate any.
Axel.Thimm at ATrpms.net