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.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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..
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.
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).
packaging@lists.fedoraproject.org
-
Axel Thimm -
Jesse Keating -
Nicolas Mailhot -
Ville Skyttä