Используете / var или / srv для данных и журналов Apache?

Я всегда настраивал Apache так:

/etc/httpd/conf/httpd.conf (основная конфигурация Apache)

<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>

Конфигурация виртуальных хостов

<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>

Я заметил, что некоторые люди создают определенную папку для веб-контента и журналов, т.е.

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

Интересно, может ли кто-нибудь пролить свет на то, почему это так? Это безопаснее сделать так? Есть ли другие причины для перемещения содержимого веб-содержимого и журналов из пути / var / .....?

Заранее спасибо :-)

Насколько я понимаю, /var/www было обычной практикой на протяжении веков, и /srv является частью усилий по стандартизации файловой системы. /var/www это прошлое, де-факто конвенция, и мы находимся в переходном периоде, когда старая конвенция постепенно заменяется новой.

Первым шагом в переходе для многих дистрибутивов часто является создание /srv и заполните его символическими ссылками, например /srv/www -> /var/www. В какой-то момент в будущем я ожидал бы увидеть, что дистрибутивы обратят это, и в этот момент файлы будут жить под /srv и символическая ссылка будет /var/www -> /srv/www. Далее в будущем, /var/www по-видимому, уйдет совсем.

Я в дополнение к мысли Майка о FHS, вот это обсуждение на форуме Ubuntu:

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

Лучший комментарий:

/ var - более старое соглашение. Он был предназначен для данных, которые меняются с течением времени («переменные данные»), таких как кеши, спул, журналы, все виды служебных и административных файлов, в то время как «пользовательские данные» будут в домашних каталогах, ... но в какой-то момент, вероятно, из-за отсутствия какого-либо другого подходящего места / var стал также местом для «данных», которые демоны будут обслуживать другим системам и пользователям (таким как базы данных и веб-страницы). Конечно, эти файлы также будут «меняться со временем», но я согласен, что между веб-сайтом и системным журналом есть разница.

Debian по-прежнему использует по умолчанию / var для данных, но, вероятно, в большинстве «старых» Linux так и поступают (например, Redhat), и большая часть документации предполагает / var для такого рода вещей, хотя я видел примеры / srv в качестве каталога данных в некоторых ( менее традиционные) руководства администратора приложений.

FWIW, CentOS 6 имеет каталог / srv, но он пуст, а Apache, например, по умолчанию использует / var / www для корневого каталога. Можно утверждать, что /srv/logs в вашем примере следует правильно разместить в /var как обычно, потому что журналы не обслуживаются вашим компьютером.

Вы можете взглянуть на следующие

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

Я также использую / srv. Это скорее то, как я это делаю, и предпочитаю это именно так.

Когда вы имеете дело с действительно большими приложениями, обычно обслуживающими данные в кластере, вы можете использовать разные серверные части (RAID, NAS ...) для / srv и / var, с двумя дополнительными преимуществами:

Ваши политики резервного копирования, репликации и моментальных снимков могут быть разными для / srv (реальные данные) и / var (журналы, временные данные ...)
Вероятно, доступ к данным в / var является последовательным, а доступ к / srv имеет тенденцию быть более случайным. Вы можете разместить / srv на более быстром сервере (NAS с большими кешами или SSD) и / var на более дешевых локальных дисках.

Это можно сделать, смешав ваши реальные данные внутри / var, но этот способ более понятен и проще в управлении.