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

Tuxfiles говорит следующее о структуре каталогов Linux:

/var:

Этот каталог содержит переменные данные, которые постоянно изменяются во время работы системы.

FHS о /var говорит следующее:

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

Затем они добавляют, что такие вещи, как журналы, почта и спулеры, помещаются в этот каталог.

Традиционно Стандартная установка Apache или Nginx или Arch на Ubuntu Linux разместит каталог в /var/www/.

Мне не кажется, что это идеальное место для размещения каталога с файлами или каким-либо содержимым, которое должно быть почти постоянным.

Почему его так часто помещают в /var?

Более субъективно, является ли это место идеальным, согласно структуре каталогов?

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

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

Тем не менее, также говорится, что решение о структуре /srv является единственной ответственностью местного администратора! Поэтому пакеты не должны помещать ничего в /srv, и дефолтный корень документа не должен быть /srv, потому что пакет (apache) не знает, что находится в /srv и ниже. Возможно, там есть репозиторий subversion с паролем в открытом виде и другие вещи. Поэтому должен быть дефолт вне /srv. Этот дефолт стал /var/www.

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

Итого: вам следует использовать /srv и соответственно настраивать ваши виртуальные хосты Apache.

На самом деле это вовсе не “традиционное” место. Традиционно все, что вы устанавливали после ОС, помещалось в /usr/local, и действительно это “Классическая компоновка пути Apache” (их слова) существует и по сей день. Долгое время это был /home/httpd.

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

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

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

#   Классическая компоновка пути Apache.
<Layout Apache>
    prefix:        /usr/local/apache2
    datadir:       ${prefix}

#   Классификация GNU соответствующая компоновка пути.
#   См. документ FSF's GNU project `make-stds` для подробностей.
<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 Darwin>
    prefix:        /usr
    datadir:       /Library/WebServer

#   Компоновка Red Hat Linux 7.x
<Layout RedHat>
    prefix:        /usr
    datadir:       /var/www

#   Компоновка SuSE 6.x
<Layout SuSE>
    prefix:        /usr
    datadir:       /usr/local/httpd

#   Компоновка BSD/OS
<Layout BSDI>
    prefix:        /var/www
    datadir:       ${prefix}

#   Компоновка Solaris 8
<Layout Solaris>
    prefix:        /usr/apache
    datadir:       /var/apache

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

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

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

Тем не менее, FHS также указывает на то, что данные www должны помещаться в /srv

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Веб-сервер Apache имеет стандартный веб-сайт под /var/www/, но рекомендуется размещать другие веб-сайты под /srv/

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

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

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

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