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:
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 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.
Please don't forget about tftp-server ;) Currently files are placed in /tftpboot directory.
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?
umm 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 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'.
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 /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.
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.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
https://fedoraproject.org/wiki/Packaging/Guidelines#No_Files_or_Directories_under_.2Fsrv