Le mercredi 27 juin 2007 à 21:23 +0200, Axel Thimm a écrit :
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.
> > > 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. :)
Bad excuse, we ship a lot of services default-disabled, we could ship
default-disabled srv layouts
> — or defaults that can not serve as examples (because their
> 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?
We can provide examples and templates. Users that know better will do
what they want as usual. No best policy is no excuse for no policy. Half
our stuff in /etc could be configured some other just as good way we
still make a choice.
A distro rpm layout is a layout that just works with distro defaults,
which is already quite a high standard.
> 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.
You can provide a default webdav/ftp/samba layout, we've done so in conf
files for years.
can't enforce a model that works for half the users and not for the
Again you're making it a special case when the same arguments could be
used to advocate no choices in most of the filesystem. We're not gentoo
we make choices for users and then let them amend our choices.
> 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
No, /var/lib/foo is mixing local apps and content, that's the kind of
mixup that got stuff kicked from /home in the first place.
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.
They should. They will someday. Or something else will deprecate /srv.
And in fact² in a
multi-domain setup one is often forced to do so to separate
That only means you have several resources, and you can map them to
several domains, not that the resources names should be domain names.