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

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

/var :

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

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

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

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

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

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

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

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

9 Solutions collect form web for “Почему корневой каталог на веб-сервере помещается по умолчанию в «/ var / www»?”

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

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

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

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

 # 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 

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

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

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

Однако FHS также вид, который WW-данные должны входить в /srv

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

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

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

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

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

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

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

Резюме: вы должны использовать /srv и соответствующим образом настроить виртуальные хосты Apache.

Причины в основном исторические, как говорили другие. /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, и в этом нет ничего плохого.

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

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

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

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

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

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

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

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

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

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

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

 #<Directory /srv/> # Options Indexes FollowSymLinks # AllowOverride None # Require all granted #</Directory> 
  • Почему iwconfig в / sbin?
  • Ноутбук нельзя использовать после удаления / bin
  • Должны ли / usr и / home находиться на разных разделах?
  • Конвенция для основной структуры развертывания приложений на Unix-подобном сервере приложений
  • Есть ли какое-либо общее значение для каталога `collects`?
  • Открытый, некорневой доступ к файловой системе?
  • Обмен каталогами в дереве, из / dir1 / dir2 / dir3 / dir4 to / dir1 / dir2 / dir4 / dir3
  • Стандартные переменные среды для путей, специфичных для распространения
  • Linux и Unix - лучшая ОС в мире.