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(a)futuresource.com