До питання про деякі аспекти організації файлової системи UNIX / Linux

1.0 Введення

Після написання попередньої статті (Linux: Установка програм не входять у дистрибутив за допомогою менеджера xstow), у мене залишилося двоїсте враження. З одного боку в статті все правильно, а з іншого боку, відгуки показали, що є деякі різночитання в призначенні різних частин ФС UNIX. Вийшло так, що я дав людям в руки молоток, дав інструкцію із застосування молотка, а які цвяхи і куди забивати цим молотком, не сказав. Спробую заповнити цей пробіл. У даній статті я спробую, наскільки мені це вдасться, розповісти, як організована ФС UNIX, навіщо це зроблено саме це так, для чого і як себе в цій системі вісті.


Надалі в якості прикладів UNIX буду використовувати дистрибутив Debian / Ubuntu.

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


2.0 Проблема: як розміщувати файли різних призначень в ОС

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


2.1 Перший варіант: сортувати файли по пакетах

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

Плюси:



Мінуси:




2.2 Другий варіант: сортувати файли за функціями в системі

Плюси:



Мінуси:




3.0 Рішення в UNIX-style

У UNIX-ах вибрано розміщення по другому варіанту. Тобто файли різних програм з однаковим функціональним призначенням, лежать в одному директорії. Наприклад виконувані файли різних програм користувача лежать в директорії / usr / bin.


4.0 Проблеми, що випливають з рішення в UNIX-style, установка софта

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


5.0 Вирішення проблем: пакетні менеджери

Надалі будемо називати менеджер пакетів МП.

Сформульована в попередньому розділі проблема в різних дистрибутивах UNIX / Linux вирішується за допомогою роботи з установки, видалення та зберігання інформації про встановлене програмне забезпечення спеціальної програмі – менеджеру пакетів. У Debian / Ubuntu цим займається dpkg. Взагалі-то це тільки одна програма з цілого набору програм, які мають відношення до цього. dpkg, це бекенд, є кілька фронтендів, apt-get, aptitude, dselect, synaptic.

Що робить МП? Принаймні в Debian / Ubuntu він займається наступним:



  1. Установка пакетів.
  2. Видалення пакетів.
  3. Відстеження залежностей (при установці пакету разом з пакетом встановлювати потрібні для даного пакету інші пакети)
  4. Установка пакетів по мережі з віддалених репозитаріїв.
  5. Ведення локальної бази даних пакунків.
  6. Ведення локальної бази даних доступних для встановлення пакетів у тому числі і по мережі.
  7. Оновлення баз даних при зміні доступних пакетів та / або їх версій.
  8. Коректне встановлення оновлень пакетів.
  9. Апгрейд всієї системи.

Чимало, як по вашому? І МП Debian / Ubuntu справляється з усім цим дійсно непогано.

Сам пакет звичайно являє собою архів файлів, опис пакету з кількома полями, і скрипти, що виконуються при установці і видаленні пакета. У Debian / Ubuntu файл пакету має розширення. Deb.


6.0 Проблеми, пов'язані з пакетними менеджерами

Як відомо, без проблем нічого не буває. Використання МП теж не виняток і приносить свої проблеми. Звичайно МП вирішує значно більше проблем, ніж приносить, але все-таки їх потрібно знати і з ними боротися. Отже, проблеми:



  1. Залежності. Це плюс використання МП з одного боку. З іншого боку відстеження залежностей це велика робота мейнтенеров пакетів. На сьогодні Debian входить 25113 пакетів. Одні пакети вимагають обов'язкової установки інших, або навпаки, є несумісні пакети. У результаті виходить велика і складна система залежностей. Все це добро потрібно треба перевірити.
  2. Іноді зустрічаються несумісні комбінації пакетів.
  3. Іноді зустрічаються всякі хитрі кільцеві залежності.
  4. У зв'язку з великою кількістю пакетів, які потрібно поєднати один з одним, іноді версії пакетів, що входять в дистрибутив застарівають.
  5. Часто в дистрибутиві присутній ПЗ не тій версії, яка нам потрібна.
  6. Незважаючи на таку велику кількість пакетів, іноді нам потрібен софт, якого взагалі немає в дистрибутиві.
  7. Ми не можемо встановлювати свій софт в директорії, де господарює МП, інакше наш софт може вступити в конфлікт із софтом, встановлюються МП. Простіше кажучи, ми можемо затерти файли, встановлені МП, або навпаки.


7.0 Вирішення проблем, пов'язаних з пакетними менеджерами, ієрархія / usr / local

Останнім часом практично весь потрібний софт є в дистрибутиві у вигляді пакетів. Але все-таки рано чи пізно як правило кожен користувач / адміністратор зустрічається з необхідністю установки софта, який не входить в дистрибутив. Зазвичай зустрічаються такі варіанти:












Проблема 1. Потрібно перекомпілювати пакет з іншими настройками.
Проблема 2. Потрібного софта немає в дистрибутиві.
Проблема 3. У дистрибутиві не та версія, яку ми хочемо.

Як бути? Як зробити це з найменшим ризиком внести збурення в роботу системи? У наявності є кілька варіантів:















Проблема 1. Рішення 1: Перекомпілювати пакет з іншими настройками. (Це якщо потрібно пакет з іншими елементами). Небезпеки практично немає, хоча можуть змінитися залежно порівняно з пакетом, откомпілірованом в дистрибутиві. Тут вже, ясний перець, через залежність відповідаєте Ви.
Проблеми 2,3 Рішення 2. Зібрати власний пакет і встановити в систему.
Проблеми 1,2,3 Рішення 3 Встановити софт зібраний з исходников в ієрархію / usr / local

З Рішення 1 ніби все ясно, давайте розглянемо докладніше Рішення 2 і Рішення 3.


Рішення 2: Зібрати власний пакет і встановити в систему.

Плюси:



  1. Можна використовувати всі можливості МП, перелічені в розділі 6.0.
  2. Якщо пакет призначений для установки на кілька машин, можна скористатися мережевими можливостями МП, створити свій репозиторій зі своїми пакетами і встановлювати / оновлювати ці пакети стандартним для МП способом.

Мінуси:



  1. Використання всіх або тільки частини можливостей МП вимагає додаткових зусиль, іноді значних. Якщо ж ними не користуватися, то який сенс у використанні МП?
  2. Якщо не перевіряти свій пакет на сумісність, то вельми вірогідна ситуація, коли ваш пакет вступить в конфлікт з іншими пакетами, причому конфлікти можуть бути найнесподіванішими.
  3. При масовому впровадженні такого підходу (створення власних пакетів), з'являється можливість появи в інтернеті маси погано відтестовані і погано сумісних між собою пакетів, як був один час с з RPM, не знаю, як у них з цим зараз.

Debian Policy 2 (Ubuntu як похідне від Debian керується їм теж) прямо говорить дві речі:



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

Якщо ПО призначено для розповсюдження та встановлення в системи Debian / Ubuntu, найкращий шлях – упаковка його ст. Deb пакети. АЛЕ! У цьому випадку ви відповідаєте за залежності, конфлікти і оновлення цього пакета.


8.0 Проблеми, пов'язані з ієрархією / usr / local



  1. Як відомо, будь-яке рішення приносить нові проблеми. Не виняток і рішення, викладене в попередньому розділі. Все добре, поки ми встановили в / usr / local один пакет, як тільки пакетів стає більше одного, з'являється погано керована купа файлів, з проблемами. описаними в розділі 4.0.
  2. Ще одна проблема, це проблема з директорією / usr / local / var Як відомо, в директорію / var записуються файли даних програм, які можуть зміняться під час роботи програми (логи, PID-и файли БД і так далі). Часто
    / Var роблять на окремій партіціі, а зараз у нас вийшло, що змінювані файли потрапили в / usr / local / var.


9.0 Вирішення проблем, пов'язані з ієрархією / usr / local, можливі воркераунди

Вирішення проблеми 1. описано в моїй статті 5, Тому докладно описувати рішення не буду. Коротенько, програми ставляться кожна в свою ієрархію в директорії / usr / local / stow, а потім, спеціальні менеджер (xstow), розставляє символьні посилання на файли програми.

Рішення проблеми 2. Цю проблему доведеться вирішувати руками. Якщо ви скористалися програмою stow, то можна, наприклад, зробити директорію з унікальним ім'ям в ієрархії / var, наприклад / var / local_var, а потім зробити посилання на неї. Але це варто робити тільки в тому випадку, якщо дійсно є така необхідність.


10.0 Ієрархія / opt

У ієрархію / opt по Полісі 2 встановлюю свій софт сторонні виробники. Вони встановлюють своє ПЗ в директорії виду / opt / package або / opt / provider.


11.0 Проблеми користувача, ієрархія / home

Знову ж таки за Полісі 2, Файли користувачів зберігаються в ієрархії / home, в директоріях виду / home / username. Якщо говорити про встановлення ПЗ, то його можна встановлювати і сюди. причому як це робити, віддано на розсуд користувача.

У яких випадках це робити?



Я зазвичай використовую суміш розкладки файлів "по директоріях" і "по пакетах". Для ПЗ, яке працює постійно, як правило, це мої скрипти, створюю директорії / home / username / bin / home / username / etc / home / username / var . Софт, який просто хочу подивитися або погратися просто компілюють в директорії / home / username / sw / softname і запускаю просто звідти.


12.0 Інші застосування ієрархії / home

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


13.0 Інші ОС

Одного разу Вовочкина мама сказала татові:
"Тобі не здається, що нашому Вовочці вже
пора розповісти про секс? "
Папа подумав, і відповів:
"Напевно ти права, тільки незручно якось."
Мама: "Ну розкажи на прикладі метеликів."
Папа покликав Вовочку і каже:
"Вовочка, пам'ятаєш ми з тобою були в
публічному домі? "
"Пам'ятаю."
"Ну так от: у метеликів все точно так само."

© Анекдот


FreeBSD

В ОС FreeBSD в принципі все також, з невеликими відмінностями. Файли базової системи там знаходяться як і у Linux сімейства Debian / Ubuntu в основний ієрархії. Бінарним пакетів там відповідають два поняття, пакети і порти.

Пакети це приблизно те ж саме, що і пакети в Debian / Ubuntu. В якості пакетного менеджера там використовується набір команд для роботи з пакетами (і портами).

Порт, це набір допоміжних файлів, який дозволяє скомпілювати і встановити вихідні коди в систему. Він дозволяє в автоматичному режимі завантажити вихідні коди з носія (наприклад CDROM) або завантажити з інтернету, скомпілювати і встановити в систему.

Як пакети, так і порти встановлюються в ієрархію / usr / local.

Точно так само, як і в Debian / Ubuntu може зустрінеться ситуація, коли для софта немає ні пакету ні порту. Тоді, природно, потрібно встановлювати софтвер з початкових кодів. Для цього можна або зробити порт для цього софтвера, або просто скомпілювати і встановити вихідні коди в ієрархію / usr / local. Звичайно, оскільки в FreeBSD там встановлюється багато софта, потрібно бути уважним, тому що ймовірність конфліктів через цього зростає.

Ну і повертаючись до методів, описаним у статті 5, Думаю, що якщо Ви не робите свого порту, для підтримки порядку, можна використовувати програму xstow. Хоча у BSD-істів можуть бути свої улюблені методи, невідомі мені, хай знають товариші мене поправлять, якщо я помиляюся.


Сімейство Windows

В ОС сімейства Windows, для розміщення софту, як правило застосовується підхід, коли для кожного пакета ПЗ – своя ієрархія. Спостерігаються деякі зрушення у бік розкладки файлів з призначень, але цьому заважають:

– Відсутність єдиного дерева файлової системою (букви, що позначають партіціі, C:, D: і т.д.).
– Традиція.
– Вимоги сумісності з напрацьованим софтом.


Висновок

Сподіваюся стаття буде корисною. У принципі можна б було в іншій статті більш докладно розібрати призначення інших директорій та ієрархій ФС UNIX / Linux.


Список використаних скорочень

































.deb Розширення файлів пакетів ПЗ для Debian / Ubuntu
dpkg dpkg – це програмне забезпечення, що є основою системи управління пакетами в Debian.
PID Ідентифікатор процесу
RPM Red Hat Package Manager – менеджер пакунків Red Hat
БД База даних
МП Менеджер пакетів
ОС Операційна система
ПЗ Програмне забезпечення
репозитарії Сховище софту з доступом за допомогою МП
ФС Файлова система


Література

1. Стандартна ієрархія файлової системи Linux (File System Hierarchy Standard)
2. Filesystem Hierarchy Standard (Доповнення до Debian Policy)
3. http://ru.wikipedia.org/wiki/RPM
4. http://ru.wikipedia.org/wiki/Dpkg
5. Linux: Установка програм не входять у дистрибутив за допомогою менеджера xstow
6. man hier

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*