Почему корневой каталог на веб-сервере помещен по умолчанию в “/var/www”?

Это - на самом деле не "традиционное" местоположение вообще. Традиционно, что-либо, что Вы установили после ОС, вошло /usr/local, и действительно это - "Классическое расположение пути Apache" (их слова) по сей день. В течение долгого времени это было /home/httpd.

То, что Вы видите, - то, что Apache, который был настроен для конкретной ОС - является ли это Red Hat Linux, Mac OS X, GNU, и т.д. - настроит местоположение. Источник Apache хорошо разработан для этого, на самом деле при трассировке значения для ServerRoot в исходных файлах Вы будете видеть, что это начинается в этом файле, config.layout:

Некоторые выборки из того файла покажут Вам, что существует большое разнообразие в docroot месте.

IIRC, /var/www вошел в мою жизнь с выпусками 2000-2001 Red Hat Linux 7.x (не Red Hat Enterprise Linux). По всем причинам Вы цитируете выше, я думал, что это не имело большого смысла - но действительность - то, что в современную эру столько других инструментов и технологий включены перемещения местоположения так или иначе.

#   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

Причины являются главным образом историческими, как сказали другие. /var использовался для системных данных, которые изменяются все время, например, файлы кэша, журналы, данные во время выполнения (файлы блокировки, например), устройство хранения данных почтового сервера, буферизация принтера, и т.д. В основном для всего материала, который не может быть вставлен /usr (потому что это содержит локальные данные), не сторонние программы, которые входят /opt, и не отбрасываемо и энергозависим, поскольку они входят /tmp.

Как разработанный Unix/Linux, это стало грязным местом с мешаниной различных отличающихся соединенных каталогов. Была тенденция в последние годы для перемещения некоторых вещей из туда, особенно довольный служил машиной (в который теперь согласно [должен войти Стандарт Иерархии Файловой системы 2.3, p.15] /srv, не в /var/www).

Подобная вещь произошла с /var/run несколько лет назад - со сконцентрированным усилием по нескольким дистрибутивам, это было перемещено от /var/run в /run который сплавленный вместе функции ранее используемого /var/lock, /var/run и /dev/shm.

В то время как я соглашаюсь с ответом akond, я думаю, что существует более важный аспект к нему. Большинство других местоположений (такой как /usr/local) обычно управляются системой (диспетчер пакетов). /var обычно, куда файлы идут, которыми не управляет диспетчер пакетов ('данные' в масштабе всей системы).

Я также думаю, что определение от FHS немного более точно (данные не должны "постоянно изменяться"):

/ var содержит переменные файлы данных. Это включает каталоги шпульки и файлы, административные и регистрирующие данные и переходные и временные файлы.

Однако FHS также разновидности, в которые должны входить www данные /srv

/srv содержит сайт-специфичные данные, которые подаются этой системой.

Эта основная цель указать это состоит в том так, чтобы пользователи могли найти местоположение файлов данных для конкретного сервиса, и так, чтобы сервисы, которые требуют единственного дерева для данных только для чтения, перезаписываемых данных и сценариев (таких как сценарии cgi) могли быть обоснованно размещены.

Методология, используемая для именования подкаталогов/srv, является неуказанной, поскольку в настоящее время нет никакого согласия по тому, как это должно быть сделано. Один метод для структурирования данных под/srv протоколом, например, ftp, rsync, www, и cvs.

IIRC, в былые дни, мы всегда монтировались /var как своя собственная файловая система (отдельный диск или часть диска).

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

Другая причина состоит в том, что назад в те дни, если Ваша система отказала во время операции записи, был очень хороший шанс, что Ваша корневая файловая система могла заставить поврежденный отъезд ее в твердом восстанавливать состояние. Таким образом потребность в разделении от /.

Файловая система и дисковая технология значительно улучшались со временем, таким образом, это - намного менее вероятное возникновение.

На основе моего опыта (я - веб-разработчик) содержание веб-сайта совсем не стабильно. Даже в случае файлов HTML (nevermind динамично сгенерированное содержание) они подвергаются постоянным изменениям (поправки, пропуск, и т.д.).

Таким образом с моей точки зрения, они - переменные. Таким образом они отлично подходят в / каталоге var и нет ничего неправильно с этим.

/var достойный выбор для нейтрального в отношении пользователя "основного" местоположения для многопользовательского доступа, в конечном счете у Вас есть веб-сайт с несколькими виртуальными хостами, работающими, который позволяет FTP или другие загрузки, т.е. если Вы - webhost или подобный.

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

Конечно, я думаю /srv лучше для этого, но /varвокруг дольше в традиции UNIX.

Что я хотел бы добавить, вот то, что помещение веб-"корня" в/usr конфликтует часть FHS, который указывает на/usr, как являющийся совместно используемым и только для чтения, так как различные веб-серверы, даже на том же "кластере" может иметь различные файлы, которые содержат различные конфигурации, и это не делает это идеалом для/usr.

Кроме того, некоторые веб-приложения (MediaWiki и PhpBB для именования тех первое, что пришло на ум) ожидают записываемое местоположение под веб-деревом каталогов для загрузок вложений/медиа-файла. Так подвергание веб-дерева под/usr конфликтовало бы, если Вы хотите придерживаться/usr определения только для чтения.

Использование / var / www запутается только с первого взгляда.

Согласно FHS, данные веб-сервера должны переходить в / SRV . Это главное правило.

Однако он также говорит, что решение о структуре / SRV является исключительной ответственностью местного администратора! Поэтому пакеты не должны ничего ставить в / srv , а по умолчанию root не должно быть / srv , потому что пакет (Apache) не знает, что в / SRV и под ним. Может быть, репозиторий Subversion с прозрачным текстовым паролем и другими вещами. Так что должно быть по умолчанию за пределами / SRV . Это по умолчанию становится / var / www .

/ var / www в основном является заполнителем. Пакеты используют / usr / Share для статического HTML-контента или / var / lib для динамического переменного контента. Многие люди ошибочно подумали, что они должны поставить HTML в / var / www . Это проблема, потому что пакеты иногда используют это тоже. Так что недавно они изобрели / var / www / html для пакетов. Надеюсь, люди не начнут использовать это, потому что снова они должны изобретать новый каталог ... и так далее.

Сводка: Вы должны использовать / SRV и настроить виртуальные хосты Apache соответственно.

Веб-сервер Apache имеет сайт по умолчанию под /var/www/, но он предлагает поместить другие сайты под /srv/

Я заметил это на Ubuntu Server 14. 04 LTS. Его стандартный файл apache2.conf содержит закомментированный блок:

#<Directory /srv/>
#   Options Indexes FollowSymLinks
#   AllowOverride None
#   Require all granted
#</Directory>