Red Hat Bugzilla – Bug 172152
Last modified: 2014-03-16 22:56:42 EDT
Description of problem:
(filing this against distribution since changes might be required in several
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
For a specific example, webroot is /var/www/html by default
Change into /srv/www in the default httpd.conf configuration. SELinux policies
might be needed. Upgrades from previous installation should retain the same settings
There was a reason we did this, I can't find the bug, though.
I think the main reason was migration was going to hurt in a big way.
also a default dav root in /srv wouldn't hurt
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.
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.
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
(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
/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.
Please don't forget about tftp-server ;) Currently files are placed in /tftpboot
a query across the filelists.xml looking for files in /var then backtracking
through it should tell us everything that needs to move.
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."
(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?
except suexec how?
would the compiled in /var/www path for apache suexec be shown by that?
/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
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
And please use /srv/www/htdocs instead of /srv/www/html while you're at it.
"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
|../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:
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.
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:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
The issue has not been dealt with. In fact it was discussed again on
fedora-devel this week
(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.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here: