On Tue, 2005-04-26 at 08:42, Matthew Miller wrote: > For the same reason we don't put user files in /var/home. See the rationale > for /var in the FHS: > > /var contains variable data files. This includes spool directories and > files, administrative and logging data, and transient and temporary > files. > > > Web server content is generally none of these. Often, it's static, important > user data. The FHS defines /var/www as specifically for "WWW proxy or cache > data". > > Really, anything a normal user might want to get at with a text editor > oughtn't be in /var. Or to put it in a way that's relevant to this thread :) > anything that's vital to preserve across upgrades. (Old logs are nice, but > not usually vital -- if they *are*, better to write them to a log server > which would store them somewhere safe.) If your web server content is important you might not want people to edit the files directly. You'll probably want to edit somewhere that you can preview, then when all the links are consistent, copy the files all at once to the public location. If you serve enough to need more than one machine, you will want a mechanism to push the copies out quickly to keep the view consistent. If you want to track changes, you may want to enforce updating through CVS or other revision control mechanism. In all of these cases, the copy under /var/www/... really is a cached or spooled copy and conceptually correct and you would certainly push a fresh copy to a new machine instead of restoring a backup of /var to preserve it. If you really want an extension of your home directory to be served by the web server you can always use a public_html subdirectory and the ~user/ notation. > Things that aren't quite perfect I can work around: I deliver mail to > maildir in users' home directories, avoiding problems with /var/mail. And > that pretty much leaves user crontabs as an annoyance. You shouldn't edit the crontab files directly either. There is a system tool for that. -- Les Mikesell les@xxxxxxxxxxxxxxxx
