Just wondering if there's any intention of moving the default locations for Apache's webroot and database files (MySQl, Postgres, et al) to /srv where they belong.
On that note, why is the PID file for MySQL stored under /var/lib/mysql rather than /var/run?
Dnia 10/19/2006 08:17 PM, Użytkownik Rex Dieter napisał:
bug?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172152 :)
Dawid Gajownik wrote:
Dnia 10/19/2006 08:17 PM, Użytkownik Rex Dieter napisał:
bug?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172152 :)
I was just asking out of curiosity, wasn't aware of the bug.
Thanks
On 10/19/06, J French me@semitekie.com wrote:
Just wondering if there's any intention of moving the default locations for Apache's webroot and database files (MySQl, Postgres, et al) to /srv where they belong.
Well it could be possible, but the /srv section is left up to the individual site to dictate layout and not the vendor (if I read the FHS correctly. So if it is called /src/www/ does that cause problems with FHS compliance?
On that note, why is the PID file for MySQL stored under /var/lib/mysql rather than /var/run?
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, Oct 19, 2006 at 02:32:20PM -0600, Stephen John Smoogen wrote:
On 10/19/06, J French me@semitekie.com wrote:
Just wondering if there's any intention of moving the default locations for Apache's webroot and database files (MySQl, Postgres, et al) to /srv where they belong.
Well it could be possible, but the /srv section is left up to the individual site to dictate layout and not the vendor (if I read the FHS correctly.
That's correct. Furthermore the FHS supports different hierarchies below /srv depending on the site's needs. For example a server hosting project1.org and project2.org would use
/srv/project1.org/www and /srv/project2.org/www
So /srv should be kept free of any package bits. I'm copying the packaging list, perhaps it's worth noting in the guide.
Le samedi 21 octobre 2006 à 04:14 +0200, Axel Thimm a écrit :
That's correct. Furthermore the FHS supports different hierarchies below /srv depending on the site's needs. For example a server hosting project1.org and project2.org would use
/srv/project1.org/www and /srv/project2.org/www
So /srv should be kept free of any package bits. I'm copying the packaging list, perhaps it's worth noting in the guide.
The FHS like many things does not specify a particular policy. This should not stop Fedora from defining one. Much better to have a consistent well-though distro policy rather than free-for-all packager mess
On Sat, Oct 21, 2006 at 12:42:53PM +0200, Nicolas Mailhot wrote:
Le samedi 21 octobre 2006 à 04:14 +0200, Axel Thimm a écrit :
That's correct. Furthermore the FHS supports different hierarchies below /srv depending on the site's needs. For example a server hosting project1.org and project2.org would use
/srv/project1.org/www and /srv/project2.org/www
So /srv should be kept free of any package bits. I'm copying the packaging list, perhaps it's worth noting in the guide.
The FHS like many things does not specify a particular policy. This should not stop Fedora from defining one. Much better to have a consistent well-though distro policy rather than free-for-all packager mess
Well-tought IMHO means not to impose any of the possible policies onto the user since different scenarios require different methodologies. So Fedora as a general purpose distibution should not freeze any degrees of freedom here.
On Sat, Oct 21, 2006 at 04:14:51AM +0200, Axel Thimm wrote:
That's correct. Furthermore the FHS supports different hierarchies below /srv depending on the site's needs. For example a server hosting project1.org and project2.org would use /srv/project1.org/www and /srv/project2.org/www So /srv should be kept free of any package bits. I'm copying the packaging list, perhaps it's worth noting in the guide.
As noted in the bug, I think that default, package-managed files should be packaged into /usr/share/somewhere, but /srv/www (or /srv/www/something/) should be the default (empty, except maybe a README) document directory.
On Sat, Oct 21, 2006 at 06:58:19AM -0400, Matthew Miller wrote:
On Sat, Oct 21, 2006 at 04:14:51AM +0200, Axel Thimm wrote:
That's correct. Furthermore the FHS supports different hierarchies below /srv depending on the site's needs. For example a server hosting project1.org and project2.org would use /srv/project1.org/www and /srv/project2.org/www So /srv should be kept free of any package bits. I'm copying the packaging list, perhaps it's worth noting in the guide.
As noted in the bug, I think that default, package-managed files should be packaged into /usr/share/somewhere,
I agree.
but /srv/www (or /srv/www/something/) should be the default (empty, except maybe a README) document directory.
No, /srv should exist, but otherwise be empty from the vendor's POV (e.g. no package should own/place anything beneath /srv). We should neither impose /srv/<service>, nor /srv/<service>/<domain>, nor /srv/<domain>/<service> methods. These are really very specific to the solution needed and prefering any of these will make the other users unhappy, and in this case all three mentioned solution have probably the same or very comparable share of users.
Instead provide anything, as you write, under /usr/share, as a template to be copied by the user somewhere under /srv according to his needs (or some similar mechanism).
A copy-to-somewhere script could be rpovided, too. For example fedora-install-mediawiki <path> or fedora-install-bugzilla <path> to name two projects that are often used in several incarnations on one system.
Le samedi 21 octobre 2006 à 13:06 +0200, Axel Thimm a écrit :
On Sat, Oct 21, 2006 at 06:58:19AM -0400, Matthew Miller wrote:
On Sat, Oct 21, 2006 at 04:14:51AM +0200, Axel Thimm wrote:
That's correct. Furthermore the FHS supports different hierarchies below /srv depending on the site's needs. For example a server hosting project1.org and project2.org would use /srv/project1.org/www and /srv/project2.org/www So /srv should be kept free of any package bits. I'm copying the packaging list, perhaps it's worth noting in the guide.
As noted in the bug, I think that default, package-managed files should be packaged into /usr/share/somewhere,
I agree.
but /srv/www (or /srv/www/something/) should be the default (empty, except maybe a README) document directory.
No, /srv should exist, but otherwise be empty from the vendor's POV (e.g. no package should own/place anything beneath /srv).
We package TFTP, FTP, SMB, CIFS, DAV servers... They all need a default root in their config file. The FHS makes it abundantly clear this root must be somewhere in /srv.
We can't refuse to choose a default because: 1. most users want us to choose a default so things "just work" 2. it's not a mere matter of writing a string in a config file: when several apps use the same resource you need to coordinate them, it has security and selinux impacts, etc 3. increasing variability only hurts documentation. If we don't decide people will make random choices in howtos that will be blindly followed because most people don't care and don't want to choose themselves
You could make the very same argument for package naming - since there is no standard and any choice will always be suboptimal in some cases why even attempt to write Fedora Naming Guidelines?
Well we wrote the damn guidelines and they're bloody useful. We don't have the freedom of the FHS to refuse to make contentious choices. We're responsible for an actual system. That requires making operational decisions. (And BTW we have historically made these decisions, only we chose roots in parts of the filesystem the FHS declared wrong, so maintaining the status-quo won't make us any more FHS compliant quite the contrary)
On Sat, Oct 21, 2006 at 01:29:02PM +0200, Nicolas Mailhot wrote:
Le samedi 21 octobre 2006 à 13:06 +0200, Axel Thimm a écrit :
On Sat, Oct 21, 2006 at 06:58:19AM -0400, Matthew Miller wrote:
On Sat, Oct 21, 2006 at 04:14:51AM +0200, Axel Thimm wrote:
That's correct. Furthermore the FHS supports different hierarchies below /srv depending on the site's needs. For example a server hosting project1.org and project2.org would use /srv/project1.org/www and /srv/project2.org/www So /srv should be kept free of any package bits. I'm copying the packaging list, perhaps it's worth noting in the guide.
As noted in the bug, I think that default, package-managed files should be packaged into /usr/share/somewhere,
I agree.
but /srv/www (or /srv/www/something/) should be the default (empty, except maybe a README) document directory.
No, /srv should exist, but otherwise be empty from the vendor's POV (e.g. no package should own/place anything beneath /srv).
We package TFTP, FTP, SMB, CIFS, DAV servers... They all need a default root in their config file.
There is no root for smb/cifs/nfs. The number of services that really require a root to be able to do something at all are quite limited.
The FHS makes it abundantly clear this root must be somewhere in /srv.
Like for imap and nis where the FHS contradicts with itself on this point?
I don't think we should interprete the FHS that we are to hardwire stuff into /srv forcing users to abandon their favourite methology. That would lead to admins quitting Fedora due to not being able to use it for their purposes. Or they would ignore /srv and create a new /srv2. Both of which are not what we'd like to happen.
Let's try to find a compromise: Would a special subfolder of /srv like /srv/default/{www,ftp,...} make you and me happy? It would have the least impact on user chosen metholodgy [1] and all services could move to there. Deal?
BTW the FHS is currently being revised, if we'd like to make a suggestion (for example a special subfolder under /srv designated to be vendor owned) we should hurry up.
[1] Unless s/o have a domain called "default", /srv/default is just a suggestion of the top of my head, there may be better ones.
No, /srv should exist, but otherwise be empty from the vendor's POV (e.g. no package should own/place anything beneath /srv). We should neither impose /srv/<service>, nor /srv/<service>/<domain>, nor /srv/<domain>/<service> methods.
Well, let me point out that SE Linux policy needs to know what is going in that location so that "the right thing" happens. We do need to impose some kind of order so that people don't bump into MAC problems and turn SE Linux off.
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Sat, Oct 21, 2006 at 01:06:31PM +0200, Axel Thimm wrote:
No, /srv should exist, but otherwise be empty from the vendor's POV (e.g. no package should own/place anything beneath /srv). We should neither impose /srv/<service>, nor /srv/<service>/<domain>, nor /srv/<domain>/<service> methods. These are really very specific to the solution needed and prefering any of these will make the other users unhappy, and in this case all three mentioned solution have probably the same or very comparable share of users.
I see it as analogous to /usr/local -- that's the local admin's domain, but Fedora *does* populate it with some typical subdirectories.
I don't think it's at all unreasonable to ship with the default document root at /srv/www, which would be empty by default. If you make anything else the document root, many people are just going to edit stuff *there*.
Anyone who wants a different arrangement than the default can edit the document root in httpd.conf, no problem, but there'd be a sensible and standard default already. From the FHS:
Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data.
What I'm suggesting covers both parts of this, not just the first.
A copy-to-somewhere script could be rpovided, too. For example fedora-install-mediawiki <path> or fedora-install-bugzilla <path> to name two projects that are often used in several incarnations on one system.
For some reason, this doesn't really feel right to me. Nothing else works like this....
I don't think it's at all unreasonable to ship with the default document root at /srv/www, which would be empty by default. If you make anything else the document root, many people are just going to edit stuff *there*.
Anyone who wants a different arrangement than the default can edit the document root in httpd.conf, no problem, but there'd be a sensible and standard default already. From the FHS:
Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data.
What I'm suggesting covers both parts of this, not just the first.
Though the current places are also standard for a long time and also covered in many books. Keeping to them and having sysadmins change them to /srv/ might keep FC/RHEL to more conservative setups and stability.
regards,
Florian La Roche
On Sat, Oct 21, 2006 at 01:06:31PM +0200, Axel Thimm wrote:
No, /srv should exist, but otherwise be empty from the vendor's POV (e.g. no package should own/place anything beneath /srv). We should neither impose /srv/<service>, nor /srv/<service>/<domain>, nor /srv/<domain>/<service> methods.
I completely agree with this. The FHS policy for /srv is explicitly worded to have no policy for /srv, so we cannot use it as packagers.
FHS says both that we must not impose any particular directory structure within /srv, and that we must use /srv as the "default location" for storing data used by services. The only way to satisfy that would be to do the equivalent of "DocumentRoot /srv" for every service, which would be simply stupid.
joe
On Mon, Oct 23, 2006 at 05:11:57PM +0100, Joe Orton wrote:
FHS says both that we must not impose any particular directory structure within /srv, and that we must use /srv as the "default location" for storing data used by services. The only way to satisfy that would be to do the equivalent of "DocumentRoot /srv" for every service, which would be simply stupid.
It doesn't say you must not have any particular defaults in srv -- just that applications must not expect it to be in any particular way. That's very different. I think it's entirely reasonable for Fedora to have a default layout, but it needs to be sure to cope properly if the local system does something different.
Le lundi 23 octobre 2006 à 12:27 -0400, Matthew Miller a écrit :
On Mon, Oct 23, 2006 at 05:11:57PM +0100, Joe Orton wrote:
FHS says both that we must not impose any particular directory structure within /srv, and that we must use /srv as the "default location" for storing data used by services. The only way to satisfy that would be to do the equivalent of "DocumentRoot /srv" for every service, which would be simply stupid.
It doesn't say you must not have any particular defaults in srv -- just that applications must not expect it to be in any particular way.
Replace applications there by third-party applications Obviously Fedora-packaged apps can expect whatever Fedora layout Fedora provides.
On Mon, Oct 23, 2006 at 07:15:48PM +0200, Nicolas Mailhot wrote:
FHS says both that we must not impose any particular directory structure within /srv, and that we must use /srv as the "default location" for storing data used by services. The only way to satisfy that would be to do the equivalent of "DocumentRoot /srv" for every service, which would be simply stupid.
It doesn't say you must not have any particular defaults in srv -- just that applications must not expect it to be in any particular way.
Replace applications there by third-party applications
No, I don't think so, actually.
Obviously Fedora-packaged apps can expect whatever Fedora layout Fedora provides.
Why is that obvious?
For example, look at /usr/local. Fedora provides a default layout there, but any Fedora-packaged program which has a problem if someone does something different is broken.
Similarly, creating a /srv/www and making it the default document root for apache is fine. However, making other packages expect it to be there isn't so good.
On Mon, Oct 23, 2006 at 01:28:32PM -0400, Matthew Miller wrote:
For example, look at /usr/local. Fedora provides a default layout there, but any Fedora-packaged program which has a problem if someone does something different is broken.
No, that's not "Fedora's" default layout, it is actually the layout as given folder by folder by the FHS, even such folders like /usr/local/games.
Similarly, creating a /srv/www and making it the default document root for apache is fine. However, making other packages expect it to be there isn't so good.
You shouldn't compare /usr/local with /srv. The former is very strictly dictated by the FHS, while /srv has the special status "free-for-all".
The only Fedora'ism (or better said the most prominent one) existing is libexecdir and in this case we're trying to persuade the FHS editors about the need for it and place it into the next FHS.
Le lundi 23 octobre 2006 à 13:28 -0400, Matthew Miller a écrit :
On Mon, Oct 23, 2006 at 07:15:48PM +0200, Nicolas Mailhot wrote:
FHS says both that we must not impose any particular directory structure within /srv, and that we must use /srv as the "default location" for storing data used by services. The only way to satisfy that would be to do the equivalent of "DocumentRoot /srv" for every service, which would be simply stupid.
It doesn't say you must not have any particular defaults in srv -- just that applications must not expect it to be in any particular way.
Replace applications there by third-party applications
No, I don't think so, actually.
Obviously Fedora-packaged apps can expect whatever Fedora layout Fedora provides.
Why is that obvious?
Because it's unreasonable to forbid an entity to rely on its own actions? The FHS wrote its specification in the context of an app installed on a foreign system, not in the context of a distro which controls the whole system
The FHS basically writes app authors must write apps so app users can configure whatever /srv/ layout they want. It says no entity can expect another entity to provide any particular /srv/ layout.
But in the context of a distribution : — we are providing a /srv/ layout for ourselves (acting in-stead of users, which is what distributions are supposed to do) — users are still free to reconfigure apps with whatever policy they prefer if they don't like the Fedora one.
I don't see how the document could be read otherwise. The alternative would be to forbid *any* pre-configuration for *any* service the FHS puts in /srv/, which is plain ridiculous (should apps ignore conf files settings and embark in automagical /srv/ exploration heuristics too? that's another absolutist reading)
And BTW pre-configuring is *safe*. *No* app author can complain Fedora is providing a particular /srv layout — the FHS forbids them to expect a particular layout. That includes an empty /srv.
On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote:
Obviously Fedora-packaged apps can expect whatever Fedora layout Fedora provides.
Why is that obvious?
Because it's unreasonable to forbid an entity to rely on its own actions? The FHS wrote its specification in the context of an app
Yeah, but Fedora is not forbidden from relying on its _own_ actions, but rather from relying on _my_ actions. Although it's perfectly reasonable for Fedora to provide a default, it shouldn't/can't rely on me or you keeping that default, because, as Axel points out, there's many perfectly good ways for arranging this directory depending on system usage.
installed on a foreign system, not in the context of a distro which controls the whole system
This is exactly the point of /srv. The distro does not control the whole system -- the sysadmin does. However, the distro should be constructed to help the sysadmin as much as possible.
The FHS basically writes app authors must write apps so app users can configure whatever /srv/ layout they want. It says no entity can expect another entity to provide any particular /srv/ layout. But in the context of a distribution : — we are providing a /srv/ layout for ourselves (acting in-stead of users, which is what distributions are supposed to do) — users are still free to reconfigure apps with whatever policy they prefer if they don't like the Fedora one.
I agree with you so far.
However, the phrasing "Fedora-packaged apps can expect whatever Fedora layout" seems to assume that add-on web packages which don't have a good mechanism for being reconfigured other than rebuilding would be free to rely on some layout for /srv. Instead, they should be fixed so they don't have to.
Additionally, there should be no risk of any local data in /srv being overwritten on package upgrade. Package-managed files shouldn't be in there. (See the cvsweb and munin rpms in extras, for example.) This is pretty straightforward -- user-edited data and RPM-handled files don't mix well. (The conf file .rpmnew/.rpmsave kludge isn't viable here.)
I don't see how the document could be read otherwise. The alternative would be to forbid *any* pre-configuration for *any* service the FHS puts in /srv/, which is plain ridiculous (should apps ignore conf files settings and embark in automagical /srv/ exploration heuristics too? that's another absolutist reading)
It works pretty well with Apache via the /etc/httpd/conf.d/welcome.conf mechanism....
Le lundi 23 octobre 2006 à 14:44 -0400, Matthew Miller a écrit :
On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote:
Although it's perfectly reasonable for Fedora to provide a default, it shouldn't/can't rely on me or you keeping that default, because, as Axel points out, there's many perfectly good ways for arranging this directory depending on system usage.
As long as Fedora can provide a default and rely on the sysadmin creating directories, updating conf files, selinux contexts, if he wishes another policy all is fine
installed on a foreign system, not in the context of a distro which controls the whole system
This is exactly the point of /srv. The distro does not control the whole system -- the sysadmin does. However, the distro should be constructed to help the sysadmin as much as possible.
Which includes providing default policies. In the APP vs USER divide the distribution is not on one side only.
However, the phrasing "Fedora-packaged apps can expect whatever Fedora layout" seems to assume that add-on web packages which don't have a good mechanism for being reconfigured other than rebuilding would be free to rely on some layout for /srv. Instead, they should be fixed so they don't have to.
Sure. To be clear: – Matthew the app writer can not hardcode /srv paths in its app or have them set at build time – Matthew the app packager, working within a distro can and should create whatever directory structure is needed in /srv and preconfigure its package to use it. If the app does not permit anything but hardcoding he should refer upstream
Additionally, there should be no risk of any local data in /srv being overwritten on package upgrade. Package-managed files shouldn't be in there.
But service roots (directories) should be there (including perhaps some %config files such as a default FTP welcome message)
settings and embark in automagical /srv/ exploration heuristics too? that's another absolutist reading)
It works pretty well with Apache via the /etc/httpd/conf.d/welcome.conf mechanism....
This is not automagical exploration that's conf file reading, including files auto-dropped by packages
On Mon, Oct 23, 2006 at 09:05:33PM +0200, Nicolas Mailhot wrote:
Le lundi 23 octobre 2006 à 14:44 -0400, Matthew Miller a écrit :
On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote:
Although it's perfectly reasonable for Fedora to provide a default, it shouldn't/can't rely on me or you keeping that default, because, as Axel points out, there's many perfectly good ways for arranging this directory depending on system usage.
As long as Fedora can provide a default and rely on the sysadmin creating directories, updating conf files, selinux contexts, if he wishes another policy all is fine
How, if the distribution defaults are in the way?
Le lundi 23 octobre 2006 à 22:04 +0200, Axel Thimm a écrit :
On Mon, Oct 23, 2006 at 09:05:33PM +0200, Nicolas Mailhot wrote:
Le lundi 23 octobre 2006 à 14:44 -0400, Matthew Miller a écrit :
On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote:
Although it's perfectly reasonable for Fedora to provide a default, it shouldn't/can't rely on me or you keeping that default, because, as Axel points out, there's many perfectly good ways for arranging this directory depending on system usage.
As long as Fedora can provide a default and rely on the sysadmin creating directories, updating conf files, selinux contexts, if he wishes another policy all is fine
How, if the distribution defaults are in the way?
Just put distributions defaults under /srv/whatever if you're afraid of collisions. With whatever being system if you're reasonable and DoctObnik! or wi.drigco if you're not
On Mon, Oct 23, 2006 at 08:08:36PM +0200, Nicolas Mailhot wrote:
would be to forbid *any* pre-configuration for *any* service the FHS puts in /srv/, which is plain ridiculous (should apps ignore conf files settings and embark in automagical /srv/ exploration heuristics too? that's another absolutist reading)
/srv is ridiculous from any sane interpretation. It got in purely because the people actually doing useful work accidentally briefly got outnumbered by people with no experience and opinions when it was voted on
is providing a particular /srv layout ??? the FHS forbids them to expect a particular layout. That includes an empty /srv.
And empty it should stay
On Mon, Oct 23, 2006 at 03:04:30PM -0400, Alan Cox wrote:
/srv is ridiculous from any sane interpretation. It got in purely because the people actually doing useful work accidentally briefly got outnumbered by people with no experience and opinions when it was voted on
Well, I certainly don't have your experience.
-
Alan Cox -
Axel Thimm -
Dawid Gajownik -
Florian La Roche -
J French -
Joe Orton -
Matthew Miller -
Nicolas Mailhot -
Rex Dieter -
Stephen John Smoogen -
Steve G