Які точки монтажу, сумісні з FHS?


14

Мені цікаво, що таке FHS-сумісні точки кріплення для внутрішніх жорстких дисків та мережевих ресурсів ? Багато різних навчальних посібників пропонують встановити їх у підкаталогах до /mntабо/media

Відповідно до стандарту FHS 3.0 (стандарт ієрархії файлів):

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

Я припускаю, що ці точки монтажу можуть бути використані /home/foo/extdrive /home/foo/nfsshareдля однієї користувацької системи, але де я можу їх встановити доступними для всіх користувачів?

Оновлення: FHS 3.0, глава 3.1, другий параграф "Обгрунтування"

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

Не відповідь, але хіба внутрішній жорсткий диск не буде частиною "звичайної" файлової системи? наприклад, у вас не вистачає місця на диску 1, зрозумійте, що це тому, що /varвін росте швидше, ніж очікувалося, і тому встановіть диск 2 і змонтуйте його як /var. Цікаве питання про: мережеві акції, це свого роду "анти /srv"!
Джон N

Відповіді:


16

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

Внутрішні приводи

/mntє дійсним місцем, щоб зробити своє, якщо хочете, і так є /.

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

Я думаю, що доцільно використовувати / mnt, якщо ви можете зробити кілька точок кріплення. Це дозволяє легко бачити їх усіх разом, і це відоме як одне з місць, якими люблять користуватися люди. Деякі інші люди люблять користуватися /Volumes- слідкуючи за системою OS X або /vol. / дані загальні для однієї точки монтажу. / d / також використовується. / диск / майже напевно використовується деякими, але це може відволікати пам’ять, яке не базується на диску.

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

Бажані точки кріплення для внутрішніх жорстких дисків

Можливо, що вручну створювати точки монтажу внизу /media- це погана ідея для деяких поширених систем. Сучасні ОС Linux створюватимуть точки монтажу для знімних носіїв автоматично, і можливо, структура, яку вони створюють, буде конфліктувати або просто виявиться невідповідною вашій власній. Ви не кажете, що ваша система, але вас можуть зацікавити портативні вказівки, особливо якщо ви питаєте про FHS. Зауважте, це міркування схоже на те, чому FHS каже, що ОС не повинна заповнюватися / mnt.

Точка кріплення для загальносистемного диска USB

Мережеві файлові системи

Іноді рекомендується встановлювати мережеві файлові системи в спеціальному підкаталозі , наприклад /n/host, /nfs/hostабо /net/hostт.п.

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


FHS каже, що /mntце тимчасові кріплення. Як щодо стійких кріплень. Хоча я пішов уперед і створив /mnt/dataдодатковий доданий диск, мені приємно мати стандартний документ, який рекомендує, які sysadmins слід використовувати для додаткових дисків. Це, головним чином, психологічна вимога.
Вівертіро

1
@eternaltyro У мене таке саме відчуття, але у відповіді WouterVerhelst вже є хороший аргумент. Я спробував розробити щось, щоб покращити це, але насправді це не вийшло. Здебільшого це було просто дублювання та перешкоджало практичним пропозиціям. Відредаговано, щоб спробувати зробити це зрозумілим.
sourcejedi

8

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

У системі Unix є лише одне дерево файлових систем. Таким чином, ви можете монтувати що-небудь в локальній системі на будь-якому місці файлової системи, і ви ні в якому разі не порушите FHS; врешті-решт, FHS намагається не вникати місцевим системним адміністраторам. Для внутрішніх дисків , які знаходяться в системі в будь-який час, це цілком допустимо , щоб мати точку монтування /optабо /ntfsабо /scratchабо етажерку. Крім того, якщо у вас не вистачає місця на диску, і ви хочете перемістити деякі елементи з вашої кореневої файлової системи та на інший диск, ви можете перенести /varабо /usrна окремий жорсткий диск і вирішити справи таким чином.

Єдине , що ви повинні НЕ зробити , це встановити внутрішній диск на місці , що FHS говорить розподілу можна записати в (наприклад /usr, /varчи /lib), а потім або не перемістити відповідні дані в цьому місці, або використовувати деякі не-POSIX файлова система для відповідного розділу. Крім цього, майже все - чесна гра.


2

Щоб зробити каталог доступним для конкретних користувачів, ви створили б групу. За умовами групи можуть мати домашні каталоги. Вони іноді, але не обов'язково, створюються як / home / $ GROUP.

Можна було б створити каталог / дім / вселюдники. Ви можете зарезервувати всі користувачі імені групи (тобто створити порожню групу), якщо хочете. (Імена користувачів і груп технічно є окремими просторами імен, але вони, як правило, підтримуються послідовними. Наприклад, ви б особливо не хотіли створювати нормальних користувачів "всекористувачі" в цьому випадку).

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

Ви не розповсюджуєте програмне забезпечення, і обґрунтування, наведені в FHS, не стосуються вас. Після цього обмеження було б введено додаткове обмеження. Якщо / home стає незмінним, це також буде менш просто монтувати / home / allusers для цілей резервного копіювання, відновлення чи усунення несправностей.


2

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

Я використовував приклади:

  • Великий фрагмент загального спільного простору на / mnt / play
  • CIFS для користувачів, що користуються, через pam-mount on / home / [ім'я користувача] / мережа / [поділитися]
  • Серверні програми відповідно до інструкції, наприклад / sapmnt / opt / what / bacula
  • Файли поділяються на / srv / [ім'я спільного доступу] або / файлових файлів / [ім'я спільного доступу]

Також варто уникати всього, що використовується автоматичним інструментом, таким як / media на Mint / Ubuntu, або використовувати перелічені дерева каталогів для чогось іншого, ніж їх призначення. Наприклад, звичайно монтувати диск в / var / [app] або / usr / [app], щоб зробити більше доступного місця для цього конкретного додатка, але не використовуйте його для чогось іншого, тому що ви отримаєте лише себе в каламуті.

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