6:08 p.m.
Sorry I couldn't make it today (and FWIW I will be quite short of time
until mid September).
On the /srv issue: The FHS is deliberately not providing any layout on
how to internally structure this, as there are at least two very
popular ones (both of them mentioned in the FHS):
/srv/<service>/[<domain>/]...
/srv/<domain>/<service>/...
As neither fits universally and Fedora is a general purpose distro we
should not impose any layout on the users but allow them to freely use
any layout they like. There are extended version of this argumentation
on this list and f-m-l
E.g. no package (other than filesytem) should ever place/own anything
under /srv. Packages that need a dummy or default data location should
use /var instead.
--
Axel.Thimm at ATrpms.net
8:38 p.m.
On Tuesday 26 June 2007 19:08:29 Axel Thimm wrote:
Sorry I couldn't make it today (and FWIW I will be quite short of
time
until mid September).
On the /srv issue: The FHS is deliberately not providing any layout on
how to internally structure this, as there are at least two very
popular ones (both of them mentioned in the FHS):
/srv/<service>/[<domain>/]...
/srv/<domain>/<service>/...
As neither fits universally and Fedora is a general purpose distro we
should not impose any layout on the users but allow them to freely use
any layout they like. There are extended version of this argumentation
on this list and f-m-l
E.g. no package (other than filesytem) should ever place/own anything
under /srv. Packages that need a dummy or default data location should
use /var instead.
I'm OK with this, just as long as we /have/ a policy to follow. +1 from me.
--
Jesse Keating
Release Engineer: Fedora
1:01 p.m.
On Wednesday 27 June 2007, Axel Thimm wrote:
On the /srv issue: The FHS is deliberately not providing any layout
on
how to internally structure this, as there are at least two very
popular ones (both of them mentioned in the FHS):
/srv/<service>/[<domain>/]...
/srv/<domain>/<service>/...
As neither fits universally and Fedora is a general purpose distro we
should not impose any layout on the users but allow them to freely use
any layout they like. There are extended version of this argumentation
on this list and f-m-l
But the FHS also says "However /srv should always exist on FHS compliant
systems and should be used as the default location for such data.".
I don't see how it would be possible to sanely satisfy all the "do not assume
any particular layout", "do not remove locally placed files in /srv"
and "use /srv as the default location for such data" requirements in packaged
software, so maybe that's a case in point for not using /srv at all.
But I think asking the FHS people for clarification before setting policies
and especially before rushing to make changes to packages that currently use
and place files in /srv would be the right thing to do.
1:08 p.m.
Le mercredi 27 juin 2007 à 21:01 +0300, Ville Skyttä a écrit :
I don't see how it would be possible to sanely satisfy all the
"do not assume
any particular layout", "do not remove locally placed files in /srv"
and "use /srv as the default location for such data" requirements in packaged
software, so maybe that's a case in point for not using /srv at all.
+1
also layouts that use domains as roots are pretty much ruled out in an
rpm context, so that's not as if we have a choice to make
--
Nicolas Mailhot
1:19 p.m.
On Wed, Jun 27, 2007 at 08:08:50PM +0200, Nicolas Mailhot wrote:
Le mercredi 27 juin 2007 à 21:01 +0300, Ville Skyttä a écrit :
> I don't see how it would be possible to sanely satisfy all the "do not
assume
> any particular layout", "do not remove locally placed files in /srv"
> and "use /srv as the default location for such data" requirements in
packaged
> software, so maybe that's a case in point for not using /srv at all.
Yes, only "filesystem" should mention /srv, e.g. create it.
+1
also layouts that use domains as roots are pretty much ruled out in an
rpm context, so that's not as if we have a choice to make
Yes, but that means more that the rpm setup within /srv is ruled out,
the way you write it may be read as "rpm doesn't support domain
hierarchies, so Fedora setups should not use them" ;)
/srv was really left alone for several Fedora Core releases (only
bittorrent would install there), we should return to that setup (and
also move bittorrent away).
$ ls /srv
alsa-project.org
atrpms.net
bittorrent
ivtvdriver.org
lm-sensors.org
medley
mythdora
video4linux.org
--
Axel.Thimm at ATrpms.net
1:41 p.m.
On Wednesday 27 June 2007, Axel Thimm wrote:
/srv was really left alone for several Fedora Core releases (only
bittorrent would install there), we should return to that setup (and
also move bittorrent away).
Moving is tricky for many packages as there can be *lots* of content installed
in the currently used dirs. It may and will in many cases require
reorganizing partitions and/or disks.
2:01 p.m.
On Wed, Jun 27, 2007 at 09:41:36PM +0300, Ville Skyttä wrote:
On Wednesday 27 June 2007, Axel Thimm wrote:
> /srv was really left alone for several Fedora Core releases (only
> bittorrent would install there), we should return to that setup (and
> also move bittorrent away).
Moving is tricky for many packages as there can be *lots* of content installed
in the currently used dirs. It may and will in many cases require
reorganizing partitions and/or disks.
True, I don't know how bittorrent's upgrading currently works, but
with moving I ment new package installs. As long as there is only
bittorrent and maybe a couple more packages polluting /srv we can have
package-local workarounds phasing the direct usage under /srv out.
For bittorrent this means that on new installs it picks the non-srv
location and on upgrades it copies over the bittorent data
location from the previous setup (probably needs to happen in %pre
before the config files are overwritten). Or maybe bittorrent needs
another approach, just giving the idea.
--
Axel.Thimm at ATrpms.net
2:09 p.m.
Le mercredi 27 juin 2007 à 21:41 +0300, Ville Skyttä a écrit :
On Wednesday 27 June 2007, Axel Thimm wrote:
> /srv was really left alone for several Fedora Core releases (only
> bittorrent would install there), we should return to that setup (and
> also move bittorrent away).
Moving is tricky for many packages as there can be *lots* of content installed
in the currently used dirs. It may and will in many cases require
reorganizing partitions and/or disks.
That's a bad argument. You could use it to block any distro change, and
waiting longer only means more systems installed with a known-bad
policy. When a better policy is agreed on there is no win in delaying
implementation.
--
Nicolas Mailhot
3 p.m.
On Wednesday 27 June 2007, Nicolas Mailhot wrote:
Le mercredi 27 juin 2007 à 21:41 +0300, Ville Skyttä a écrit :
> On Wednesday 27 June 2007, Axel Thimm wrote:
> > /srv was really left alone for several Fedora Core releases (only
> > bittorrent would install there), we should return to that setup (and
> > also move bittorrent away).
>
> Moving is tricky for many packages as there can be *lots* of content
> installed in the currently used dirs. It may and will in many cases
> require reorganizing partitions and/or disks.
That's a bad argument. You could use it to block any distro change,
Aww, please.
and
waiting longer only means more systems installed with a known-bad
policy. When a better policy is agreed on there is no win in delaying
implementation.
Even if the "better policy" is essentially just a new interpretation of a
(still) ambiguous, kind of self conflicting standard, and would in some cases
mean knowingly breaking existing perfectly well working setups on upgrades?
I don't think I can agree with that.
What I can agree with is applying the new interpretation to newly introduced
packages, and after the ambiguity in the specification has dissolved and the
new interpretation been in practice for quite a while without no pressure to
change it again in sight, only then inflicting the breakage, loud and clear,
unless no other migration path is found.
1:41 p.m.
Le mercredi 27 juin 2007 à 20:19 +0200, Axel Thimm a écrit :
On Wed, Jun 27, 2007 at 08:08:50PM +0200, Nicolas Mailhot wrote:
> also layouts that use domains as roots are pretty much ruled out
in an
> rpm context, so that's not as if we have a choice to make
Yes, but that means more that the rpm setup within /srv is ruled out,
the way you write it may be read as "rpm doesn't support domain
hierarchies, so Fedora setups should not use them" ;)
That is exactly what I meant.
Using the filesystem namespace to express domain separations is broken
by design in any autodeploy/autoupdate context. That people can get by
in a manual deployment context does not make it any less broken (there's
a lot of stuff which is cheap with a human operator and insane with an
automaton)
The *only* sane policy in an automated context is domain-agnostic file
locations + domain policy in conf files (which allows transparent domain
aliasing BTW). I've spent time enough as a webapp ISV engineer trying to
workaround the tomcat≥3 stupid policy of forcing a domain file layout on
everyone to have a clear opinion on the subject.
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.
--
Nicolas Mailhot
1:52 p.m.
On Wed, Jun 27, 2007 at 08:41:43PM +0200, Nicolas Mailhot wrote:
Le mercredi 27 juin 2007 à 20:19 +0200, Axel Thimm a écrit :
> On Wed, Jun 27, 2007 at 08:08:50PM +0200, Nicolas Mailhot wrote:
> > also layouts that use domains as roots are pretty much ruled out in an
> > rpm context, so that's not as if we have a choice to make
>
> Yes, but that means more that the rpm setup within /srv is ruled out,
> the way you write it may be read as "rpm doesn't support domain
> hierarchies, so Fedora setups should not use them" ;)
That is exactly what I meant.
Well, see below.
Using the filesystem namespace to express domain separations is
broken
by design in any autodeploy/autoupdate context. That people can get by
in a manual deployment context does not make it any less broken (there's
a lot of stuff which is cheap with a human operator and insane with an
automaton)
The *only* sane policy in an automated context is domain-agnostic file
locations + domain policy in conf files (which allows transparent domain
aliasing BTW). I've spent time enough as a webapp ISV engineer trying to
workaround the tomcat≥3 stupid policy of forcing a domain file layout on
everyone to have a clear opinion on the subject.
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. rpm can
either not have /srv at all, or enforce only one of three popular
models pissing off two thirds of the users.
But we want all users to continue to use Fedora/RHEL, so we let /srv
to the users' mercy only, and keep our packages away from it.
--
Axel.Thimm at ATrpms.net
2:06 p.m.
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
— or defaults that can not serve as examples (because their layout has
no relation with the /srv/ users are supposed to use), confuse scripts
(again because of the layout mismatch), confuse security policies, etc
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.
--
Nicolas Mailhot
2:23 p.m.
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
other half.
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.
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
2:39 p.m.
On Wednesday 27 June 2007 15:23:27 Axel Thimm wrote:
/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.
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.
I think the key thing here is that the FHS seems contradictory with regard
to /srv and we really would like some clarification so that we can create
appropriate packaging guidelines.
--
Jesse Keating
Release Engineer: Fedora
8:02 p.m.
On Wed, Jun 27, 2007 at 03:39:51PM -0400, Jesse Keating wrote:
On Wednesday 27 June 2007 15:23:27 Axel Thimm wrote:
> /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.
>
> 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.
I think the key thing here is that the FHS seems contradictory with regard
to /srv and we really would like some clarification so that we can create
appropriate packaging guidelines.
The FHS is knowingly partial "contradictory" in some places, because
the FHS' self-assigned task is not to design a hierarchy on the
blackboard, but to capture best practices. The (old) discussion about
bin64 or arch'd bindirs in general for example shows that while the
FHS has been favourable towards this, they decided to not introduce it
until a distribution shows actual interest in implementing it.
People are concentrating their system's data under /srv mainly for
mount and backup strategies, not because /var/lib wouldn't fit. The
simple singleton non-virtualized applications can live very nicely
under /var as they have actually been doing for a couple of
decades. It's the more complex setups that make /srv attractive, and
populating /srv with a fixed layout will make Fedora too inflexible
for exactly the traget group that would benefit the most.
So actually introducing a fixed layout into /srv party discards its
existence. Consider /srv more similar to /usr/local and /home instead
of any other vendor controlled filesystem path.
--
Axel.Thimm at ATrpms.net
1:18 a.m.
Le jeudi 28 juin 2007 à 03:02 +0200, Axel Thimm a écrit :
People are concentrating their system's data under /srv mainly
for
mount and backup strategies, not because /var/lib wouldn't fit.
Right. And the policy you're advocating is backup this bit if the admin
used the default conf, and backup another one if he changed it.
That's plain insane.
You have
/home user data
/var/lib system apps data
/srv data served by the system to other systems
simple clean easy to understand
So actually introducing a fixed layout into /srv party discards its
existence.
Please read the start of the thread again. I never advocated locking
out /srv in a fixed layout. I advocated making a fixed layout in /srv
for our needs, in a specific part of /srv, letting admins do whatever
they want this the rest of /srv.
I don't care if you want to organise stuff in /srv by domain zodiacal
sign or dog name. I want the same ability I have on the rest of the
filesystem, preconfigure stuff for users that do not have advanced
needs. The binary you vs me is stupid there's zip reason we can not both
create structures in /srv as long as there is a clear partitioning
convention so we do not step on each other foot.
--
Nicolas Mailhot
4:39 a.m.
On Thu, Jun 28, 2007 at 08:18:09AM +0200, Nicolas Mailhot wrote:
Le jeudi 28 juin 2007 à 03:02 +0200, Axel Thimm a écrit :
> So actually introducing a fixed layout into /srv party discards its
> existence.
Please read the start of the thread aga
I wrote the start of the thread ...
I never advocated locking out /srv in a fixed layout.
You did by advocating to hardcode it into the packages.
I advocated making a fixed layout in /srv for our needs,
"Our" needs? How do you define "our"? With my Fedora hat on I say
that
"our" needs are to fulfill our various certainly non-marginal
different user groups from small home setups to large systems. This is
only accomplished by not applying any "Fedora layout" that is only
chosen because "that's what rpm can do". That's a very poor design
criterion for a layout-free entity.
in a specific part of /srv, letting admins do whatever they want
this the rest of /srv.
/srv/I_hope_noone_has_been_using_this_folder_where_I_put_all_defaults_in
I don't care if you want to organise stuff in /srv by domain
zodiacal
sign or dog name. I want the same ability I have on the rest of the
filesystem, preconfigure stuff for users that do not have advanced
needs.
/var
The binary you vs me is stupid there's zip reason we can not
both
create structures in /srv as long as there is a clear partitioning
convention so we do not step on each other foot.
And the clear convention to step not on each other's feet is to not
use any default layout, neither by zodiac, nor your dog's names.
OK, to put this to an end (because we don't produce any new
arguments), we agree that we disagree, and the FPC makes its vote once
its members feel confident that they have the whole picture..
--
Axel.Thimm at ATrpms.net
2:48 p.m.
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
7:52 p.m.
On Wed, Jun 27, 2007 at 09:48:32PM +0200, Nicolas Mailhot wrote:
Bad excuse, we ship a lot of services default-disabled, we could
ship
default-disabled srv layouts
Yes, but nuking an rpm captured rpm layout means breaking rpm.
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.
$ ls /srv
ftp
httpd
foo
bar
$ rm -fr /srv/*
$ for domain in $domains; do mkdir -p /srv/$domain/{ftp,httpd,foo,bar}; done
$ rpm -V vsftp httpd foo bar
missing /srv/ftp ...
missing /srv/httpd ...
...
No, not really.
A distro rpm layout is a layout that just works with distro
defaults,
which is already quite a high standard.
There is no single standard, and there is good reason for that.
> 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.
See, above, we don't have an rpm attribute that says "possibly ignore
the following layout" liiiike we have with %config.
> 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.
No, this comparision is not fair. Or give an example. The popular
modeeeels in /srv usage are really relevant and break each other.
We're not gentoo we make choices for users and then let them
amend
our choices.
Ouch. No, we're a general purpose distro with different users, we will
neither send the home user, not the professional syadmin home.
> > 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.
This hierarchy holds state information pertaining to an application or
the system.
> 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.
They can't. Because there are choices that you can deprive the users from.
> 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.
No, I wrote instances vs virtual setups (although the latter got
trimmed).
--
Axel.Thimm at ATrpms.net
6140
days inactive
6142
days old
packaging@lists.fedoraproject.org
18 comments
4 participants
participants (4)
-
Axel Thimm -
Jesse Keating -
Nicolas Mailhot -
Ville Skyttä