[Fedora-packaging] Re: /srv

Nicolas Mailhot nicolas.mailhot at laposte.net
Wed Jun 27 19:48:32 UTC 2007

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. 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. :)

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 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?

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.

> And you
> can't enforce a model that works for half the users and not for the
> other half.

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
> well.

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
> instances. 

That only means you have several resources, and you can map them to
several domains, not that the resources names should be domain names.

Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20070627/2346ee80/attachment.sig>

More information about the Fedora-packaging mailing list