Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Tuxfiles says the following about the Linux directory structure:

/var:

This directory contains variable data that changes constantly when the system is running.

FHS on /var says the following:

/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.

They then go on to say that things like logs, mail and the spooler are put in that folder.

Traditionally A stock installation of Apache or Nginx on Ubuntu Linux will place the directory at /var/www/.

It doesn't seem to me like the ideal place to put a directory with files or otherwise content that is supposed to be almost permanent.

Why is it so often put into /var?

More subjectively, is this where it should ideally go, according to the directory structure?

share|improve this question
1  
This is a good question that I asked myself often too and arranged with it somehow :). –  wolf Sep 7 '12 at 6:48
1  
According to FHS /var/lib/www would have been more suitable... –  Nils Sep 7 '12 at 20:21
add comment

7 Answers

From my experience (I am a web developer) web site content is far from stable. Even in case of html files (nevermind dynamically generated content) they are subject to constant changes (amendments, omissions, etc.).

So from my point of view, they are variables. Thus, they are perfectly suited in the /var directory and there is nothing wrong with that.

share|improve this answer
1  
I would disagree. I still don't see HTML files as "constantly changing". Changes made to them are deliberate and would ideally be checked into a revision-control for change tracking. –  jonallard Sep 8 '12 at 20:45
    
Changes to the Mysql database are also deliberate, yet database files are located in /var/db. Does not bother you? –  akond Sep 8 '12 at 21:03
1  
Sure does, but I would argue that on the continuum from variable to constant, the DB would be more variable than the HTML/whatever/web application, since there are fewer versions of the web pages than there is of the database. The pages having relatively few different versions, I would not put in /var. But I think it is a matter of opinion and debate rather than hard facts. –  jonallard Sep 8 '12 at 21:13
    
What would you say if I show you a database that has not been changed for two years? –  akond Sep 8 '12 at 21:26
    
"Holy shit that's an old database version!", would be what I would say. :) I was speaking generally. –  jonallard Sep 8 '12 at 21:54
add comment

It's actually not the "traditional" location at all. Traditionally, anything you installed after the OS went into /usr/local, and indeed that's the "Classical Apache path layout" (their words) to this day. For a long time, it was /home/httpd.

What you're seeing is that an Apache that has been configured for a particular OS -- whether that's Red Hat Linux, Mac OS X, GNU, etc - will customize the location. Apache's source are well designed for this, in fact if you trace the value for the ServerRoot in the source files, you'll see that it starts out in this file, config.layout:

Some excerpts from that file will show you that there's a lot of variety in the docroot location.

IIRC, /var/www came into my life with the 2000-2001 releases of Red Hat Linux 7.x (not Red Hat Enterprise Linux). For all the reasons you cite above, I thought it didn't make great sense - but the reality is that in the modern era so many other tools and technologies are involved the location moves anyway.

#   Classical Apache path layout.
<Layout Apache>
    prefix:        /usr/local/apache2
    datadir:       ${prefix}

#   GNU standards conforming path layout.
#   See FSF's GNU project `make-stds' document for details.
<Layout GNU>
    exec_prefix:   ${prefix}
    datadir:       ${prefix}/share+

#   Mac OS X Server (Rhapsody)
<Layout Mac OS X Server>
    prefix:        /Local/Library/WebServer
    datadir:       ${prefix}

#   Darwin/Mac OS Layout
<Layout Darwin>
    prefix:        /usr
    datadir:       /Library/WebServer

#   Red Hat Linux 7.x layout
<Layout RedHat>
    prefix:        /usr
    datadir:       /var/www

#   SuSE 6.x layout
<Layout SuSE>
    prefix:        /usr
    datadir:       /usr/local/httpd

#   BSD/OS layout
<Layout BSDI>
    prefix:        /var/www
    datadir:       ${prefix}

#   Solaris 8 Layout
<Layout Solaris>
    prefix:        /usr/apache
    datadir:       /var/apache
share|improve this answer
add comment

While I agree with akond's answer, I think there is a more important aspect to it. Most of the other locations (such as /usr/local) are typically managed by the system (the package manager). /var is usually where files go that are not managed by the package manager (system wide 'data').

I also think the definition from the FHS is a bit more accurate (the data does not have to be "constantly changing"):

/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.


However the FHS also species that www data should be going into /srv

/srv contains site-specific data which is served by this system.

This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed.

The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs.

share|improve this answer
    
Errr, the whole point of /usr/local is that its not managed by the package manager. –  derobert Sep 7 '12 at 16:06
    
@derobert /usr/local gets used a lot by 3rd party packages (packages not provided by the distro's repo). It's also common for companies who build their own packages to put them in there (though that still falls under packages not provided by distro). This is supported by the FHS as well, see note #27 at the very bottom of pathname.com/fhs/pub/fhs-2.3.html –  Patrick Sep 7 '12 at 17:41
    
/srv/www was the classical path on SuSE-systems (up to SLES10), too. –  Nils Sep 7 '12 at 20:19
    
@nils wait, they were compliant with FHS and then deliberately left it??? sigh –  Patrick Sep 7 '12 at 21:40
    
@Patrick yeah, my comment didn't describeit fully , it's at the discretion of the administrator... That could mean using the package manager, stow, completely by hand, or a mix of them ... –  derobert Sep 8 '12 at 11:53
show 1 more comment

The reasons are mostly historical, as others said. /var has been used for system data that changes all the time, for example cache files, logs, runtime data (lock files, for example), mail server storage, printer spooling, etc. Basically for all stuff that can't be put in /usr (because it contains local data), are not third-party programs which go in /opt, and is not discard-able and volatile as these go in /tmp.

As Unix/Linux developed, it became messy place with a hodge-podge of various dissimilar directories put together. There has been a tendency in recent years to move some things out of there, particularly content served by the machine (which now as per [Filesystem Hierarchy Standard 2.3, p.15] should go in /srv, not in /var/www).

Similar thing happened to /var/run a few years back -- with the concentrated effort of several distributions, it was moved from /var/run into /run which fused together the functions of the previously used /var/lock, /var/run and /dev/shm.

share|improve this answer
add comment

/var is a decent choice for a user-neutral "base" location for multiuser access, in the event you have a website with multiple virtual hosts running that allows FTP or other uploads, i.e. if you are a webhost or similar.

/home is possibly not optimum because bad things could happen to other user shell accounts if a unthinking or malicious user uploads to the /home partition limit (assuming traditional setup of /var, /home, etc. being on separate partitions) it can affect other user accounts.

Of course I think /srv is better for this but /var's been around longer in the UNIX tradition.

share|improve this answer
    
Distributions and distributed packages should adhere to the FHS. The end "user" (sysadmin if its a server) can do as she wants and put the web site wherever. I've been putting websites in /home/pub or /home/web since before there was /srv. But if I were to distribute a web server software project today, /srv/www or whatever FHS says would be the default, though the admin can change it. –  Skaperen Sep 9 '12 at 2:22
add comment

IIRC, in the olden days, we always mounted /var as it's own filesystem (separate disk or slice of a disk).

One of the reasons for this this, as others have stated, is that there is heavy reading/writing to that filesystem (logs/et al). Having a separate disk/slice means it can be better tuned for this type of I/O (versus mostly read on /, /usr, etc...).

The other reason is that back in those days, if your system crashed during a write operation, there was a very good chance that your root filesystem could get corrupted leaving it in a hard to repair state. Thus the need for separation from /.

Filesystem & disk technology has greatly improved over time, so this is a far less likely occurrence.

share|improve this answer
add comment

What I'd like to add here is that putting the web "root" in /usr conflicts the part of the FHS that indicates /usr as being share-able and read only, since different web servers, even on the same "cluster" can have different files that contain different configurations, and this does not make it ideal for /usr.

In addition, some web applications (MediaWiki and PhpBB to name the ones off the top of my head) expect a write-able location under the web directory tree for attachments/media file uploads. So putting the web tree under /usr would conflict if you wish to adhere to the read-only /usr definition.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.