Home / server / Questions / 380353
Accepted
leftcase
Asked: 2012-04-18 10:48:32 +0800 CST

Using /var or /srv for Apache data and logs?

  • 772

I've always configured Apache like this:

/etc/httpd/conf/httpd.conf (Main Apache config)

<Directory />
   Options None
   AllowOverride None
   Order deny,allow
   Deny from all 
</Directory>


<Directory "/var/www/html">
    Options None
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

Virtualhosts config

<VirtualHost *:80>
        ServerName xxxxx.co.uk
        ServerAlias xxxxx.co.uk xxxxx
        DocumentRoot /var/www/html/xxxxx.co.uk   
        ErrorLog /var/www/log/xxxxx.co.uk
        <Directory "/var/www/html/xxxxx.co.uk">
                AllowOverride None
                Options -Indexes -FollowSymLinks
                Order Allow,Deny
                Allow from all
        </Directory>
 </VirtualHost>

I've noticed that some people seem to create a specific folder for web content and logs, i.e

/srv/html/xxxxx.co.uk
/srv/log/xxxxx.co.uk

I wonder if anyone could throw any light onto why that is? Is it more secure to do it like this? Are there any other reasons to move web content content and logs out of the /var/..... path?

Thanks in advance :-)

centos redhat apache-2.2

4 Answers

  1. My understanding is that /var/www has been the common practice for ages, and /srv is part of a filesystem standardization effort. /var/www is the past, defacto convention, and we're in a transitional period where the old convention is being gradually phased out in favor of the new convention.

    The first step in the transition for many distributions is often to create /srv and fill it with symlinks, for instance /srv/www -> /var/www. At some point in the future I would expect to see distributions reverse this, at which point the files would live under /srv and the symlink would be /var/www -> /srv/www. Further in the future, /var/www would presumably go away altogether.

    • 7
  2. Best Answer

    I addition to Mike's point about FHS, here's this discussion from an Ubuntu forum:

    http://ubuntuforums.org/showthread.php?t=1425726

    The best comment is:

    /var is an older convention. It was meant for data that changes over time ("variable data") such as caches, spool, logs, all sorts of housekeeping and administration files, while "user data" would be in home directories, ... but at some point, probably by lack of any other suitable place, /var become also the place to "data" that daemons would serve to other systems and users (such as databases and web pages). Granted, those files would also 'change over time' but I agree there's a difference between a website and a system log.

    Debian still defaults to /var for data, but probably most 'old' linuxes do (eg Redhat) and most documentation assumes /var for this sort of stuff as well, although I've seen examples of /srv as data directory in some (less traditional) applications' admin guides.

    FWIW, CentOS 6 has a /srv directory, but it's empty, and Apache, for a prime example, defaults to /var/www for the root directory. One can make the case that /srv/logs in your example should properly be placed in /var as is customary, because logs aren't things being served by your machine.

    • 6

  3. You can take a look at the following

    http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

    I use /srv also. It's more of that's how I do it and prefer it that why type of thing though.

    • 4

  4. When you are dealing with really big applications, usually serving data within a cluster, you can use different backends (RAID, NAS...) for /srv and /var, with two additional benefits:

    • Your backup, replication and snapshot policies can be different for /srv (real data) and /var (logs, temps...)

    • Probably, the access to data in /var is sequential, while acces to /srv tends to be more random. You can put /srv in a faster backend (NAS with big caches or SSDs) and /var in cheaper local disks.

    It could be done mixing your real data inside /var, but this way is much more clear and easier to manage.

    • 3