FS#1857 - apache's DocumentRoot

Attached to Project: Arch Linux
Opened by Dale Blount (dale) - Tuesday, 30 November 2004, 19:57 GMT
Last edited by Pierre Schmitz (Pierre) - Monday, 14 July 2008, 01:37 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity Low
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

placing files in /home/ causes problems for boxes with /home mounted as nfs. most other distros place DocumentRoot in /var/www/ or /usr/local/ or some other place that is local to that server. /var isn't typically nfs mounted (at least mounted and shared between servers, by spec).
This task depends upon

This task blocks these from closing
 FS#5876 - Lighttpd should not install to /home/lighttpd 
Closed by  Pierre Schmitz (Pierre)
Monday, 14 July 2008, 01:37 GMT
Reason for closing:  Fixed
Additional comments about closing:  webservers are using /srv/http now.
Comment by Dale Blount (dale) - Tuesday, 30 November 2004, 19:58 GMT
also if you use -f to get the package to install, removing the package from one server will remove the files from any other server possibly using the shared /home
Comment by Jason Chu (jason) - Tuesday, 30 November 2004, 23:11 GMT
How do we go about making an upgrade path? I wouldn't want an apache upgrade to remove custom changes of users. Some may argue that breaking an install across upgrades is bad enough, but as long as it's easily migrated I don't have a problem with it.
Comment by Martin Lefebvre (dadexter) - Wednesday, 01 December 2004, 16:33 GMT
Well, would removing apache remove /home/http? or just the files that were part of the initial install?

Comment by Dale Blount (dale) - Wednesday, 01 December 2004, 17:24 GMT
Just files part of the orignal install. However, say on box1 you changed index.html to your new web page (overwriting the default Arch page). You remove apache on box2 b/c you no longer need it. It would remove your index.html because it doesn't check that it removes the same (size,md5sum) file it put there (IIRC).
Comment by arjan timmerman (blaasvis) - Sunday, 26 March 2006, 11:26 GMT
well the last isn't true anymore since pacman 2.9.8, so it now should be possible ?
Comment by Dale Blount (dale) - Sunday, 15 October 2006, 13:11 GMT
It's still a royal pain to have apache installed on boxes with shared /home. I would still like this considered. Anyone else?
Comment by Jason Carr (jason2) - Tuesday, 19 December 2006, 21:53 GMT
I agree with this feature request. I mount nfs on /home/. Please move the docroot elsewhere for Apache. I think Red Hat/Fedora uses /var/www/html. That would be peachy-keen.
Comment by Jason Chu (jason) - Monday, 12 March 2007, 20:34 GMT
The new FHS says /srv/www, IIRC.
Comment by Dale Blount (dale) - Monday, 12 March 2007, 20:37 GMT
ew.

that is all.
Comment by Roman Kyrylych (Romashka) - Monday, 12 March 2007, 20:45 GMT
but what if user installs few http servers? I guess we'll get nice file conflicts.
Comment by Dale Blount (dale) - Monday, 12 March 2007, 20:54 GMT
postfix and exim (and others) provide smtp-server and conflict with smtp-server. maybe a similar route here is necessary.
Comment by Roman Kyrylych (Romashka) - Monday, 12 March 2007, 20:59 GMT
It's pretty OK to have different webservers installed at the same time.
Why not make roots as /srv/{apache,lighttpd,nginx,cherokee,hiawhatha,webfs...} and create symlink to /srv/www in post_install? I think it won't violate FHS and will solve the issue.
Comment by Jason Chu (jason) - Tuesday, 04 September 2007, 18:36 GMT
/srv/{apache,lighttpd,...} is ok. I don't really like the idea of creating symlinks though. What's the purpose? Each web server will have things configured differently anyway. Why do we need a /srv/www if we split things up by package?
Comment by Roman Kyrylych (Romashka) - Wednesday, 05 September 2007, 11:14 GMT
Symlinking idea was to make /srv/www for webapps working out of the box (because such packages alerady exist for a long time in community).
But since we all don't like webapps as pacman packages (they can be just untarred manually and anyway they always require manual config) - I must confess that this idea was... ehm... not good :P

Loading...