Bug 172152 - FHS 2.3
FHS 2.3
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
http://www.pathname.com/fhs/pub/fhs-2...
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-31 16:28 EST by Rahul Sundaram
Modified: 2014-03-16 22:56 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-01 16:45:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rahul Sundaram 2005-10-31 16:28:23 EST
Description of problem:

(filing this against distribution since changes might be required in several
packages)

Recent versions of Fedora provide /srv as specified in FHS 2.3 but does not
change the default webroot or ftp directory amoung others as specified in the
standard

Actual results:

For a specific example, webroot is /var/www/html by default

Expected results:

Change into /srv/www in the default httpd.conf configuration. SELinux policies
might be needed. Upgrades from previous installation should retain the same settings

Additional info:
Comment 1 Bill Nottingham 2005-10-31 16:44:32 EST
There was a reason we did this, I can't find the bug, though.
Comment 2 Jeremy Katz 2005-10-31 16:56:33 EST
I think the main reason was migration was going to hurt in a big way.
Comment 3 Nicolas Mailhot 2006-05-13 09:15:30 EDT
also a default dav root in /srv wouldn't hurt
Comment 4 Reuben Farrelly 2006-05-13 18:59:00 EDT
We could probably start by creating and owning /srv/www - which as of now does
not even exist.

I'm not sure if there are any smart ways to hard and/or softlink the various
directories at least for one release cycle so as to give people time to migrate?

Regardless, if the change is to be made, perhaps now a good time in the release
cycle to do so.

Comment 5 Michael A. Peters 2006-05-13 19:25:17 EDT
When they made the change from /home/httpd /var/www - what they did was create a
default web page saying "not seeing what you are expecting to see?" and then
explained the change.

That would probably sufficient.

If it is going to be done - the DocumentRoot going to /srv is only one change.

icons and manual etc. should probably go into /usr/share/apache/ since it is not
content the end user changes.
Comment 6 Nicolas Mailhot 2006-05-14 14:07:10 EDT
the /srv migration is a bit more tricky

The FHS kindly tells us to put stuff which is served to users in /srv, but not
what the /srv layout is or what rules to follow to organise it.

Some stuff needs to be access by ftp-only, cifs-only, dav-only, http-only
Other stuff needs to be shared between server daemons

I doubt if you setup all the fedora daemons to own /srv people will be amused
Comment 7 Michael A. Peters 2006-05-14 14:40:55 EDT
(In reply to comment #6)
> the /srv migration is a bit more tricky
> 
> The FHS kindly tells us to put stuff which is served to users in /srv, but not
> what the /srv layout is or what rules to follow to organise it.
> 
> Some stuff needs to be access by ftp-only, cifs-only, dav-only, http-only
> Other stuff needs to be shared between server daemons
> 
> I doubt if you setup all the fedora daemons to own /srv people will be amused


What I'm doing on my own system -

/srv/www/html for apache
/srv/mysql for mysql
/srv/ftp for ftp etc.

It works well, and allows /srv to be its own partition so that on upgrades I can
do a clean install wiping /var but keeping all that data.

I do have to do some chcon stuff for SELinux to be happy - but that's to be
expected.

/srv should be owned by the filesystem package, the daemons should own the
subdirectories within /srv where they put their stuff. There are already daemon
packages in Extras that do this.
Comment 8 Dawid Gajownik 2006-05-14 15:10:15 EDT
Please don't forget about tftp-server ;) Currently files are placed in /tftpboot
directory.
Comment 9 Seth Vidal 2006-10-19 15:11:14 EDT
a query across the filelists.xml looking for files in /var then backtracking
through it should tell us everything that needs to move.
Comment 10 Matthew Miller 2006-10-19 20:56:08 EDT
My suggestion is to put default, not-designed-to-be-modified files in
/usr/share. Then, make /srv/www the document root, but leave it empty (or
populate it with a default directory structure, but that's it).

That separates user-generated content from system data, which I think is part of
the point of /srv in the first place.

This fits bothpart of "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."
Comment 11 Need Real Name 2006-10-20 17:15:46 EDT
(In reply to comment #9)
> a query across the filelists.xml looking for files in /var then backtracking
> through it should tell us everything that needs to move.

Except suexec, I think?
Comment 12 Seth Vidal 2006-10-20 17:30:30 EDT
umm
except suexec how?
Comment 13 Need Real Name 2006-10-21 05:12:27 EDT
would the compiled in /var/www path for apache suexec be shown by that?
Comment 14 Axel Thimm 2006-10-21 07:25:29 EDT
/srv should be left empty by the distribution, or more specifically by the
packages at first time install. There are at least three very popular methods to
use /srv and chosing one of them will make 2/3 of users unhappy. All three have
their merits, e.g. a simple server vs a server hosting services for several
projects:

o /srv/<service>
o /srv/<service>/<domain>
o /srv/<domain>/<service>

It would be better to have instantiator scripts that create an instance of some
service under a given path like `fedora-install-http /srv/my.org/www' or
`fedora-install-mysql /srv/mysql/other.com'.
Comment 15 Peter Backes 2007-04-07 15:42:38 EDT
And please use /srv/www/htdocs instead of /srv/www/html while you're at it.
Comment 16 J French 2007-09-17 14:38:18 EDT
"html" is fewer characters than "htdocs" ;)

if it helps any, my layout on web servers goes something like this:

/srv/mysql/ (currently /var/lib/mysql)
/srv/postgres/ (currently /var/lib/pgsql)
/srv/httpd/localhost -> link to server's default domain
/srv/httpd/TLD/DOMAIN/SUBDOMAIN
   |../cgi-bin -> cgi scripts
   |../logs -> logs for this virtual host
   |../html -> document root

This has the effect of making locating the document root or logs for any given
domain *very* easy as well as facilitating an easy to understand permissions
structure and exporting of full subdomains to other systems. For example,
exporting a full subdomain to a developer's system so they can easily get to
their own service files AND logs, the latter which many people seem to forget
developers find useful.

Given this, some decent default values might be to just set up:
/srv/mysql/
/srv/postgres/
/srv/httpd/localhost/

By default, /srv/httpd/localhost/ would be arranged in the same manner as I have
for a domain above (with cgi-bin, html and logs subdirectories) and it would
lend itself to easy expansion by those who use the web server for more than one
domain in whatever manner they wanted.
Comment 17 Bug Zapper 2008-04-03 12:36:13 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 18 Nicolas Mailhot 2008-04-03 12:48:55 EDT
The issue has not been dealt with. In fact it was discussed again on
fedora-devel this week
Comment 19 Axel Thimm 2008-04-03 18:08:55 EDT
(In reply to comment #17)
> If you can reproduce this bug in a maintained Fedora version (7, 8, or
> rawhide), please change this bug to the respective version and change
> the status to ASSIGNED.

Done. Although IMHO this bug should be closed as NOTABUG, but not before it is
officially voted on by the FPC.
Comment 20 Bug Zapper 2008-05-13 22:03:13 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.