Який найбільш підходящий каталог, де розміщувати файли, якими поділяються користувачі?


82

Або: куди я можу розмістити файли, що належать до групи?

Припустимо, в системі Unix є два користувачі: Джо і Сара . Вони обидва учасники групи любителів кіно . Де я повинен розмістити їхні файли фільмів?

  • /home/{joe,sarah}/moviesне підходять, оскільки ці каталоги належать Джо / Сара , а не їхній групі;

  • /home/movies-enthusiastтеж не підходить, тому що любитель фільмів - це група, а не користувач;

  • /var/movies-enthusiast це може бути варіантом, але я не впевнений, що це дозволено FHS;

  • /srv/movies-enthusiast Можливо, це теж варіант, однак фільми - це не файли, необхідні системним службам.


6
Голосували за згадку про FHS! Цей * nix користувач та випадковий адміністратор sys 20 років не знали про нього. Дякую!
CPRitter

Відповіді:


71

Не використовуйте

  • /usrпризначено для даних, доступних лише для читання. Дані тут повинні змінюватися лише з адміністративних причин (наприклад, встановлення нових пакетів.)
  • /opt як правило, для програм, які є автономними або потребують ізоляції від решти системи з якихось причин (наприклад, програми з медами для низьких і середніх взаємодій).
  • /varпризначено для "файлів, вміст яких, як очікується, постійно змінюватиметься під час нормальної роботи системи --- таких як журнали, файли котушки та тимчасові файли електронної пошти." Мені подобається думати про це так: якщо ваші дані не будуть виглядати правильно узагальненими у списку, вони, як правило, не належать /var(хоча з цього є винятки.)

Використовуйте

  • /homeпризначений для домашніх каталогів користувачів. Деякі бачать цей каталог також областю для групових файлів. FHS фактично зазначає, що "у великих системах (особливо коли / home каталоги поділяються між багатьма хостами, що використовують NFS), корисно розділити домашні каталоги користувачів. Підрозділ може бути здійснено за допомогою підкаталогів, таких як / home / staff, / home / гостей, / дому / студентів тощо. "
  • /srvє прийнятним і часто бажаним місцем для групових файлів. Я взагалі використовувати цей каталог для файлів спільно групових з тієї причини , зазначеної в Кріса Даун відповіді ; Я бачу груповий обмін файлами як послугу, яку надає сервер.

Див. Головну сторінку hier (7) ( man hier) для отримання додаткової інформації про призначення кожного каталогу, описаного FHS.


1
Я припускаю, що в деяких більш загальних випадках можна використовувати /srv/dataкаталог для файлів даних.
Віктор Ярема

3
+1 за згадування людини hier. Я не знав, що існує.
Зак Бойд

Дякуємо, дуже корисна інформація та посилання для нового користувача Linux.
Шивам

28

На мою думку, правильне місце /srv/movies-enthusiast. "Служба" не повинна бути демоном або програмою, вона просто повинна бути службою, яку надає система (наприклад, можливість отримувати там свої фільми). Ось цитата з FHS :

/ srv містить дані про сайти, які обслуговуються цією системою.

Я, безумовно, думаю, що ваше використання підпадає під таке визначення і надає послугу.


Я припускаю, що в деяких більш загальних випадках можна використовувати /srv/dataкаталог для файлів даних.
Віктор Ярема

11

Hierarchy Standard Filesystem (FHS) визначає макет для «розробників Unix розподілів, розробників пакету і системи реалізаторів» , щоб дотримуватися, щоб не наплутати ваше простір імен.

Оскільки це ваш простір імен, ви повинні вибрати будь-яке ім’я, яке вважаєте за потрібне. Якщо ви знайдете /groups/movies-enthusiastсенс, вам слід покласти його туди. Якщо вам подобаються назви коротких шляхів, тому що їх простіше вводити /g/movies-enthusiast(або, можливо, /g/m-e) було б доречно.

Оскільки вибрані вами шляхи не визначені в FHS, дистрибутивні або сторонні пакети не повинні торкатися їх. Таким чином, ви повинні прочитати FHS, щоб знати, якими шляхами може користуватися сумісне програмне забезпечення (зміст розповість вам більшість того, що вам потрібно знати).

Наприклад, я особисто використовую /avтам, де зберігаю свій аудіовізуальний вміст, /srcдля вихідного коду та /dataдля невизначених даних (таких як зображення віртуальної машини, CD-карти, хроноти, збережені пакети тощо).


Я особисто використовую / дані для всіх таких файлів, потім / дані / фільми для аудіовізуального контенту, / data / src для вихідного коду, / data / music. все в одному (ієрархічному) місці.
медуз

Дотримуватися або дотримуватися стандартів дуже часто є хорошою ідеєю, навіть якщо ви не розробник, дистрибутив, pkg розробник або системний впроваджувач.
Феліпе Альварес,

Додавання нового каталогу не проти FHS; власне, я б заперечував, що для створення нових каталогів колись потрібно залишатися сумісними з FHS ! FHS спеціально зазначає, що будь-яке питання, яке не потрібно узгоджувати між декількома сторонами, виходить за рамки цього стандарту. Тому, намагаючись підлаштувати всі можливі потреби всередині одного із визначених FHS каталогів, обов'язково створюються ситуації, коли файли поміщаються всередину каталогів там, де вони не повинні бути.
jwatkins

7

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

Особливо, якщо це головна мета цієї системи, я б просто створив

/ ентузіаст фільмів

Якщо є інші подібні "групи", я можу або не хочу віддавати перевагу їх розміщення разом, наприклад

/data/movies-entusiast
/data/next-group
etc

або

/share/movies-enthusiast
/share/next-idea
etc

Питання, які слід врахувати: чи збираєтесь ви присвятити для цього точку моменту?

Ви розглядали софтпосилання?

У будь-якому випадку немає правил. Якщо ви хочете зробити одного користувача зберігачем і надати решті доступ до цього простору проекту, сміливо розміщуйте його в домашньому каталозі користувача. Або створити простір імен / home / shared / *. Ви власний начальник.

О, одне: що б ви не робили, документуйте це. Це повинно стати частиною відновлення системи, щоденних перевірок, резервного копіювання тощо. Необхідно відзначити важливі затримки конфігурації (наприклад, членство в групі, набори дозволів, fs налаштування для продуктивності та все інше, що не є типовим)


1

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

Якщо його крапка, то переконайтесь, що вона є одночасно жорсткою та липкою. Також переконайтесь, що ті, хто його використовує, мають корисний умаск. Однак не використовуйте колесо, як я це робив у прикладі режимів доступу до файлів. Не знімайте eXecute, або вас чекає сюрприз O_o.

bash-3.2$ mkdir movies
bash-3.2$ sudo chmod 03771 movies
Password:
bash-3.2$ ls -ld movies/
drwxrws--t 2 andrewb wheel 68 Apr  4 17:09 movies/
bash-3.2$ umask 026
bash-3.2$ touch movies/junk
bash-3.2$ ls -l movies/
total 0
-rw-r----- 1 andrewb wheel 0 Apr  4 17:09 junk

1

Важливо пам’ятати, що FHS вирішує проблеми, коли розміщення файлів потрібно координувати між різними сторонами, такими як локальні сайти, дистрибуції, програми, документація тощо ; FHS не намагається встановити правила для кожної окремої ситуації: локальне розміщення локальних файлів - це локальна проблема ( FHS 3.0, розділ 1.1 ).

Тому ви можете технічно розміщувати свій moviesкаталог де завгодно, доки він не буде суперечити конвенціям FHS . Все-таки ваше запитання стосувалося найбільш підходящого місця, тому давайте розглянемо декілька поширених відповідей (упорядкованих найбільш переважними моїми менш бажаними, враховуючи конкретний випадок використання):

  • /<someprefix>/<groupname>або /media/<volumename>/<groupname>: Я, чесно кажучи, не знаю, чому ця опція має погану репутацію у світі Linux, але давайте уточнимо: це справді ваша система, і FHS каже, що ви вільні від створення нових каталогів на рівні коренів так як ви не конфліктуєте ні з чим, для чого існує усталена семантика. Ви можете, наприклад, створити каталог /groupsабо /sharedвпорядкувати файли в них, як вважаєте за потрібне. Я знаю, що деякі адміністратори вважають за краще, щоб вони були дещо ізольованими від решти файлової системи, тому вони монтують чіткий том (тобто під. /media/<volumename>/<groupname>). Обидва чудово, і обидва - комплаєнт FHS.

  • /srv/<groupname>або /srv/<someprefix>/<groupname>: Згідно з FHS, /srvмістить дані, що стосуються конкретних сайтів, які обслуговуються цією системою . FHS далі пояснює, що методологія, яка використовується для імені підкаталогів / srv, не визначена . З мого особистого досвіду, більшість адміністраторів, які експлуатують /srvкаталог , діють із підкаталогом на кожного клієнта, на сайт або на проект, а потім розміщують каталоги даних на цьому рівні. Однак ви її структуруєте, то/srvцілком прийнятно зберігати файли, якими слід ділитися між декількома користувачами, якщо ви обгрунтовано можете вважати, що обмін цими файлами - це послуга сама по собі. Запитайте себе: "Чи має сенс врешті ділитися цими файлами через SMB / NFS / AFS / GIT / ...?" Якщо так, то ви можете обґрунтовано вважати, що ваш каталог - це локальна послуга спільного використання файлів, і таким чином зберігати їх у підкаталозі /srv, хоча демон фактично не обслуговує ці файли в інших системах.

  • /home/<groupname>або /home/<some-prefix>/<groupname>: FHS каже: /homeце досить стандартна концепція, але це, очевидно, файлова система, що залежить від сайту . Не існує абсолютно жодної вимоги, щоб кожен каталог під /homeіменем фактичного користувача, і прийнятно мати підкаталоги для груп, хоча необхідні заходи обережності, щоб уникнути можливих конфліктів між групою та користувачем. Тим не менш, я бачив цю стратегію, яка використовується в декількох великих установках (зокрема, університетах) з певною стратегією розділення, щоб уникнути можливості конфлікту; наприклад, справжні користувачі матимуть свої домашні каталоги /home/students/<studentid>, /home/teachers/<username>або /home/staff/<username>, наприклад, розміщуватимуться спільні речі/home/workgroup/<workgroupname>. Колись вони також будуть підрозділом департаменту; все-таки ви отримуєте ідею. Якщо чесно кажучи, мені особисто ця стратегія не подобається, але вона трохи полегшує ситуацію, коли /homeвона розподіляється між декількома серверами (наприклад, через NFS), і тому вона, як правило, надається перевагу в дуже великих організаціях.


0

Я особисто вибрав би / usr / share / любитель фільмів або / opt / любитель фільмів


0

Я пропоную створити окремий каталог, як / opt / movies, встановити відповідні дозволи для користувачів та груп, а також ви можете використовувати диск, quotaщоб уникнути загального споживання диска ..


0

Це настільки ж коментар, як відповідь (тому, будь ласка, не зволікайте мене за це!), Але це занадто довго, щоб вмістити коментар.

Я роблю дві речі, обидві яких уникають проблеми, з якою ви стикаєтесь.

1) Я роблю окремий розділ всього вільного простору на моєму системному диску і маркую його на область даних. Ось куди йдуть усі мої поточні медіа-файли та інші дані. Він стає автоматизованим як / media / dataspace, і я поміщую все, що є "data", під каталог, який називається "data", щоб відокремити його від таких речей, як робочі файли, vms або iso-образи, які я не хочу регулярно створювати резервні копії.

Використання окремого розділу має додаткову перевагу, що якщо він заповнюється, він не ставить під загрозу мою систему, як це було б, якби вона зберігалася під / або / домашньою.

2) Я розміщую більшість моїх даних / медіа, особливо речей, якими я не користуюся "зараз", на інший фізичний привід (USB в моєму випадку з ноутбуком). Це дозволяє легко створити резервну копію та легко приєднати до іншого комп'ютера, якщо виникне потреба.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.