Чому кореневий каталог на веб-сервері за замовчуванням розміщено у "/ var / www"?

Tuxfiles говорить про структуру каталогу Linux:

/var:

Цей каталог містить змінні дані, які постійно змінюються під час роботи системи.

Про FHS/var йдеться про наступне:

/varмістить файли змінних даних. Сюди входять каталоги та файли котушки, адміністративні та реєстраційні дані та перехідні та тимчасові файли.

Потім вони продовжують говорити, що такі речі, як журнали, пошта та шпулер, містяться у цій папці.

Традиційно фондова установка Apache або Nginx на Ubuntu Linux розмістить каталог у /var/www/.

Мені не здається ідеальним місцем для розміщення каталогу з файлами чи іншим вмістом, який повинен бути майже постійним.

Чому його так часто вводять /var?

Більш суб’єктивно, чи це ідеально там, де вона повинна ідети, відповідно до структури каталогів?

Насправді це зовсім не "традиційне" місце розташування. Традиційно все, що ви встановили після операційної системи, перейшло до цього /usr/local, і справді це "Класичний макет шляху Apache" (їх слова) донині. Довгий час так було /home/httpd.

Що ви бачите, це те, що Apache, який був налаштований для конкретної ОС - будь то Red Hat Linux, Mac OS X, GNU тощо, - налаштує місцеположення. Джерело Apache добре розроблене для цього, адже якщо ви відстежите значення для ServerRoot у вихідних файлах, ви побачите, що воно починається в цьому файлі config.layout:

Деякі уривки з цього файлу покажуть вам, що в розташуванні docroot дуже багато різноманітності.

IIRC, /var/wwwувійшов у моє життя з випусками Red Hat Linux 7.x (2000-2001) (не 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/wwwбентежить лише з першого погляду.

Відповідно до FHS, дані веб-сервера повинні надходити /srv. Це головне правило.

Однак це також говорить про те, що прийняття рішення про структуру Росії /srv- це виключна відповідальність місцевого адміністратора! Тому пакунки нічого не повинні містити /srv, і коріння документа за замовчуванням не повинно бути /srv, тому що (apache) пакет не знає, що знаходиться в ньому /srvта під ним. Можливо сховище субверсії з чітким текстовим паролем та інші речі. Тож має бути за замовчуванням поза межами /srv. Цей дефолт стане /var/www.

/var/wwwє переважно заповнювачем. Пакети використовують /usr/shareдля статичного вмісту HTML або /var/libдля динамічного змінного контенту. Багато людей помилково думали, що їм слід потім вводити HTML /var/www. Це проблема, тому що пакети періодично також використовують це. Так нещодавно вони винайшли /var/www/htmlдля пакетів. Сподіваємось, люди не почнуть цим користуватися, тому що їм знову доведеться вигадувати новий каталог ... і так далі.

Підсумок: слід відповідно використовувати /srvта налаштувати віртуальні хости Apache.

Хоча я згоден з відповіддю Аконда, я думаю, що в цьому є важливіший аспект. Більшість інших місць (таких як /usr/local) зазвичай управляє системою (менеджером пакетів). /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 і в цьому немає нічого поганого.

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

Однією з причин цього, як заявили інші, є те, що в цю файлову систему (логи / та ін.) Існує чисте читання / запис. Наявність окремого диска / зрізу означає , що він може бути краще налаштований для цього типу I / O ( по порівнянні з головним читати далі /, /usrі так далі ...).

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

Технологія файлової системи та диска з часом значно покращилася, тому це набагато менш вірогідне явище.

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

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

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

Що я хотів би додати тут, це те, що введення веб-корінця в / 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>