Чи повинні веб-сайти жити в / var / або / usr / відповідно до рекомендованого використання?


62

Згідно з посібником по структурі директорій Linux , /usr/це для файлів додатків і /var/для файлів, які змінюються (я припускаю, що це означає "файли, що належать до додатків"). Це правильно?

Якщо це так, то я трохи розривається між використанням будь-якого. Веб-сайт - це додаток (якщо це динамічно, так би мовити), але в інших випадках це лише набір файлів, які використовує Apache.

Www dir живе за замовчуванням /var/www/, тож ми повинні слідувати прикладу, використовуючи /var/websites/(чи щось подібне), чи обирати, /usr/websites/оскільки вони можуть бути додатками?

Це дуже тривіальне питання, але все-таки це мене клопоче. У нашому випадку я схиляюся /usr/webчи щось подібне, оскільки наші веб-сайти - це всі програми.

Оновлення:

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


10
Я не думаю, що питання таке тривіальне; насправді це досить добре. Цікаво.
Арон Ротвевель,

Відповіді:


63

За даними FHS , /usrце shareable, read-only data- не те, де ви хочете розмістити веб-сайт. Тут ви повинні ввести свій код (наприклад, Fedora робить це для Wordpress). Дивіться також посібник з упаковки веб-активів для Fedora.

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

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

Інше поширене місце для розміщення файлів сайту /home- створення спеціального користувача, який називається websiteабо такого, а потім розміщення файлів всередині homedir цього користувача (наприклад, /home/website).


4
Ах, моя робота використовує /srv- як я ніколи цього не бачив, я вважав, що це створено ними. Це річ Redhat / CentOS?
Нік Болтон

12
За замовчуванням встановлено лише те, /var/wwwщо дистрибутивам не можна торкатися /srv; тобто для налаштування системного адміністратора. Отже, тому це "набагато рідше", а також правильно.
Майкл Хемптон

28

Погляньте на стандарт ієрархії файлової системи ( Вікіпедія ). Я сам використовую / srv / web / $ domain / {htdocs, logs, cgi-bin, ...}.


3
Мені це теж подобається, але замість "www" я завжди використовую назву послуги "httpd". Тож у мене є домен / srv / httpd / $ ... або / srv / smbd / sharename ... Ось так це простіше зрозуміти, яка служба обслуговує файли. Наприклад, для деяких систем у нас є домен / srv / nginx / $
Raffael Luthiger

9

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

Оновлення:

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


7

Остаточне керівництво - це стандарт ієрархії файлової системи, який говорить, що /srvце належне місце.


2
Я не читаю це таким чином - або, принаймні, я читаю це як неоднозначне з цього приводу. Більшість веб-сайтів обслуговуються не просто by this system, вони обслуговуються цілим кластером систем; і два речення, що починаються з того This setup will differ from host to host., що підказують, що це не місце для файлів, що діляться на багатьох серверах. Це досить вірогідне місце, хоча - безумовно, більш підходяще ніж /usrі, мабуть, краще, ніж/var
Джеймс Поллі

1
Я не думаю, що FHS зовсім не остаточний. Re: (З Вікіпедії): Більшість дистрибутивів Linux дотримуються FHS і заявляють, що це власна політика щодо підтримання відповідності FHS. Однак переважна більшість (станом на 2009 р.) Дистрибуцій, у тому числі розроблені членами Групи вільних стандартів, повністю не відповідають запропонованому стандарту.
Майкл Графф

6
Це приємна річ у стандартах - на вибір так багато! :)
Джеймс Поллі

3

Де вони живуть на диску, має мало значення. Це там, де ти їх хочеш.

У мене є симпосилання з / www на всіх моїх машинах до місця, де вони насправді живуть, тому мені ніколи не доводиться дивуватися від машини до машини. На деяких старих машинах є / u0 та / u1 для користувацьких дисків, і я розміщую там веб-речі. Деякі мають / монтують будинок безпосередньо, тому вони йдуть туди, але / www завжди вказує на потрібне місце.

Я також не ставлю жодної конфігурації в / usr, ні в / var. Він переходить у / local (що, ви вже здогадалися, є символьним посиланням десь на / u0 або / u1, як правило). Це полегшує резервне копіювання речей. Я просто створюю резервну копію диска користувача.

Звичайно, у мене є майстер-сайт дистрибуції для моєї ОС на вибір, NetBSD. Я роблю систему такою, якою я її хочу на цій головній машині (дійсно екземпляр xen) і rsync / usr навколо. Полегшує моє життя.


6
Це добре, якщо ви працюєте з однією людиною або, можливо, навіть невелика команда, яка тісно співпрацює і добре знайома з корінням один одного - навчитися «правильному» способу зробити це, ймовірно, буде потрібно довше, ніж просто робити це. Якщо у вас велика операція і ви часто приводите нових людей на борт, вам доведеться пришвидшити їх з такою схемою, як це забирає багато часу - дотримуватися (або принаймні близько до) FHS є збирається заощадити час з кожною новою людиною, яку ви залучите до команди.
Джеймс Поллі

5
Коли ви використовуєте 8 різних ОС, власні стандарти набагато простіше вивчити, ніж кожен-os-do-it-it-own.
Майкл Графф

1
@James Polley Скільки часу потрібно, щоб сказати про новий прокат "ми помістили речі /path/we/chose"?
ceejayoz

@ceejayoz Якщо у вас є більше приблизно двох категорій "матеріалів", набагато простіше сказати їм "ми слідуємо за FHS", хоча це може зажадати додаткових деталей для деяких категорій "речей".
tripleee

3

Веб-сервер Apache має веб-сайт за замовчуванням під / var / www /, але пропонується розмістити інші веб-сайти під / srv /

Я помітив це на Ubuntu Server 14.04 LTS. Файл apache2.conf за замовчуванням містить коментований блок:

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

2

На мою думку, ви ніколи і ніколи не повинні розміщувати будь-які Інтернет-сервіси на загальній системній зоні.

Ваші Інтернет-сервіси (Apache / Tomcat / SSH тощо) - це вхідні двері, тож якщо ви розмістите ці послуги у зоні системи, ви будете потенційно вразливі до деяких атак.

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

Ось приклад структури, яку ви можете використовувати:

/ --> Root System --> On SDA1 --> Root and System security operator access only
 |
 | -->/usr /etc /var etc.

/SRV --> Web Root --> On SDB1 --> Web users access with minimal rights access.
 |
 |-->/srv/bin & /srv/dta
      |
      |-->/srv/bin/apache (or any other APPLICATION Binaries)
      |-->/srv/dta/SQL (or any other APPLICATION Datas like a 
                        database or web PHP files etc.)

1
Чи можете ви розширитись на "загальній системній зоні"? Це не термін, який я чув раніше, і я не впевнений, що ти маєш на увазі. /srv/binсхоже, порушує FHS, який стверджує, що /srvдля даних, а не для двійкових файлів
Джеймс Поллі

Добре поширена системна зона означає частину ОС, де зберігаються всі компоненти системи, такі як обліковий запис, пароль, бінарні файли адміністратора та бібліотека. Я знаю, що моя установка не поважає повністю FHS, але я можу повністю розділити ОС на дві частини. 1 ° / - Система, яка досить виправлена ​​(за винятком встановлення інструментів оновлення та адміністрування) 2 ° / - Додатки, дані та батьківщина батьків. Таким чином, якщо у вас виникнуть проблеми з системою або даними, ви не втратите всі дані.
Д-р I

Я бачу. Це має сенс - саме тому більшість настільних комп’ютерів, наприклад, розміщені /homeна окремому розділі - ви можете видути все на нерозділі /homeі не турбуватися про втрату даних користувачів. +1 для поділу даних.
Джеймс Поллі
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.