Віктор Костромін
Структура каталогів поняття чисто логічне і до реальних механізмів роботи з файлами відношення не має. Кожна конкретна операційна система могла б будувати її по-своєму, що призвело б до несумісності і непереносимості програм. Групою ентузіастів був розроблений стандарт FHS ієрархії файлових систем для Unix-подібних операційних систем.
Будь-який користувач знаком сьогодні з поняттями файлу та каталогу (з точки зору Unix каталог той же файл) [1-3]. Групою ентузіастів зі спільноти розробників програм з відкритим кодом була запропонована специфікація структури каталогів для Unix-подібних систем, так званий стандарт ієрархії файлових систем (Filesystem Hierarchy Standard, FHS).
Робота над FHS почалася в серпні 1993 року зі спроби упорядкувати структуру файлів і каталогів Linux. Спочатку його називали проектом стандартів файлової системи Filesystem Standards Project (FSSTND), а перша версія була випущена 14 лютого 1994 року. На початку 1995 року було поставлено завдання щодо створення більш загальної версії FSSTND, призначеної не лише для Linux, але і для інших Unix-подібних систем, в першу чергу BSD 4.4. З огляду на розширення сфери дії стандарту, його перейменували в FHS (www.pathname.com / fhs). Стандарт увібрав позитивні якості, властиві BSD та інших систем в частині підтримки різних архітектур і врахування вимог роботи в гетерогенних мережах.
По-перше, враховувалося, що, хоча в Unix-подібних системах структура каталогів представлена у вигляді єдиного дерева, окремі його «гілки» можуть розташовуватися на різних носіях або в різних файлових системах. Розміщення файлів на різних носіях дозволяє оптимізувати процеси завантаження, подальшого функціонування та можливого оновлення системи. При цьому файлові системи можуть фізично розташовуватися на різних комп'ютерах і бути різними за своєю внутрішньою організацією (ext2fs, vfat і т.д.). По-друге, будь-яка Unix-система - система мережна. Тому при розміщенні окремих файлів у різних частинах файлової структури враховувалося, що деякі файли повинні бути доступні з інших комп'ютерів у мережі, а до інших файлів доступ по мережі необхідно обмежити. Група неподільні файлів вичленяються як з міркувань безпеки, так і просто тому, що ці файли визначають локальну конфігурацію системи і тому потрібні тільки на даному комп'ютері. Виділення групи поділюваних файлів дозволяє також економити загальний дисковий простір. По-третє, існують файли, змінювати які може тільки адміністратор, і ті, які будь-який користувач може міняти самостійно. До числа статичних належать виконувані файли, бібліотеки, документація та ін Для рядових користувачів ці файли повинні бути доступні тільки на читання. Знання цих передумов допомагає зрозуміти логіку розміщення окремих файлів і каталогів в структурі каталогів, пропонованої стандартом FHS.
Кореневий каталог
Стандарт FHS пропонує створити в кореневому каталозі наступні підкаталоги:
bin - файли основних команд (утиліт), які необхідні, коли ніяка інша файлова система ще не змонтована (наприклад, в режимі одного);
boot - незмінні файли, необхідні для завантаження системи;
dev - файли пристроїв;
etc - файли конфігурації системи на даному комп'ютері;
home - домашні каталоги користувачів (факультативно);
lib - основні колективні бібліотеки та модулі ядра;
lib - основні Спільні бібліотеки для альтернативних форматів (факультативно);
mnt - точку монтування для тимчасово підключаються файлових систем;
root - домашній каталог користувача root (факультативно);
opt - додаткові пакунки програмного забезпечення;
sbin - основні системні виконувані файли;
tmp - тимчасові файли;
usr - ієрархію другого рівня;
var - змінні дані.
Відповідно до вимог стандарту додатки не повинні створювати файли і каталоги або вимагати наявності якихось спеціальних файлів і каталогів (крім перерахованих) у кореневому каталозі. По-перше, розмір кореневої файлової системи бажано зберігати по можливості малим, а по-друге, стандарт FHS забезпечує достатню гнучкість і зручність розміщення файлів, що не потрапили в кореневу систему, в інших файлових системах і підкаталогах. Деякі підкаталоги кореневого каталогу факультативні. Але вже якщо вони існують, то повинні розміщуватися в кореневому каталозі, але не обов'язково в кореневій файловій системі.
Каталог / bin містить команди, які можуть використовуватися як адміністратором, так і рядовими користувачами, причому тільки ті команди, які необхідні, коли ніяка інша файлова система, крім кореневої, ще не змонтована (наприклад, в режимі одного). Ті програми які не так важливі, щоб розміщуватися в кореневій файловій системі, повинні розміщуватися в каталозі / usr / bin. В / bin обов'язково повинні бути такі команди (або символічні посилання на них): cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, false, hostname, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true, umount, uname, csh, ed, tar, cpio, gzip, gunzip, zcat, netstat, ping. У каталозі / bin не повинно бути підкаталогів.
Каталог / boot містить все, що необхідно в процесі завантаження, виключаючи конфігураційні файли і установника карти завантаження. Ядро операційної системи має розташовуватися або в кореневому каталозі /, або в / boot; програми, необхідні завантажувачу для організації завантаження файлів, повинні розміщуватися в / sbin, а конфігураційні файли завантажувача - в / etc.
/ Dev - місце розташування спеціальних файлів пристроїв. На випадок, якщо буде потрібно створювати файли пристроїв вручну, каталог / dev повинен утримувати команду MAKEDEV, яка може створити файл пристрою в разі потреби.
Каталог / etc містить конфігураційні файли і каталоги, специфічні для даної конкретної системи, але в ньому не повинно бути двійкових файлів. У відповідності зі стандартом FHS каталог в обов'язковому порядку повинен містити підкаталог / opt, в якому повинні розміщуватися підкаталоги з файлами налаштувань окремих пакетів та програм. Для кожного встановленого пакету повинен створюватися конфігураційний каталог / etc / opt / package. У каталозі / etc повинні міститися такі каталоги і файли:
/ X11 - конфігураційні файли X Window;
/ Sgml - конфігураційні файли для SGML і XML;
csh.login - загальносистемний ініціалізаційний файл для csh;
exports - список контролю доступу для мережевої файлової системи NFS;
fstab - постійна інформація для монтування файлових систем;
ftpusers - список контролю доступу для демона FTP;
gateways - список шлюзів для демона routed;
gettydefs - установки терміналу, використовувані демоном getty;
group - список груп користувачів у системі;
host.conf - файл конфігурації для системи розпізнавання імен;
hosts - постійна інформація про імена хостів;
hosts.allow - список хостів, з яких дозволений доступ до системи;
hosts.deny - список хостів, з яких заборонений доступ до системи;
hosts.equiv - список довірених хостів для rlogin, rsh, rcp;
hosts.lpd - список довірених хостів для демона друку lpd;
inetd.conf - конфігураційний файл для демона inetd;
inittab - конфігураційний файл для демона init;
issue - повідомлення, що видається системою до реєстрації користувача;
ld.so.conf - список каталогів для пошуку поділюваних бібліотек;
motd - повідомлення, що видається системою після реєстрації користувача;
mtab - динамічно змінюється інформація про змонтованих файлових системах;
mtools.conf - конфігураційний файл для mtools
networks - статична інформація про мережеві імена;
passwd - файл паролів користувачів;
printcap - база даних з настройками принтерів для демона lpd;
profile - загальносистемний файл ініціалізації для оболонки, що запускається при вході користувача в систему;
protocols - перелік IP-протоколів;
resolv.conf - конфігураційний файл для системи розпізнавання імен;
rpc - перелік протоколів віддаленого виклику процедур;
securetty - файл зі списком пристроїв, з яких може заходити користувач root;
services - імена портів для мережевих служб;
shells - список наявних в системі оболонок;
syslog.conf - конфігураційний файл для демона syslogd.
Файл mtab не відповідає незмінної природі файлів, розміщених в / etc, і поміщений в даний каталог у вигляді виключення, з історичних причин.
У невеликих системах кожен домашній каталог користувача є одним з безпосередніх підкаталогів каталогу / home, таких як / home / smith, / home / operator і т.д. У великих системах (особливо коли каталоги / home є розділяються між багатьма хостами) корисно об'єднати домашні каталоги в групи, ввівши підкаталоги груп, такі як / home / staff, / home / students. Оскільки структура домашніх каталогів різниться від хоста до хосту, ніяких вимог на неї не накладається.
/ Lib містить спільні бібліотеки потрібні для завантаження системи і запуску команд з каталогів / bin і / sbin. Принаймні, один з файлів, відповідних кожному з наступних шаблонів, повинен знайтися в даному каталозі (це можуть бути або реальні файли, або символічні посилання): libc.so. *, динамічно під'єднуються бібліотеки Сі; ld *, завантажувач / часу виконання . Не повинні розташовуватися в / lib Спільні бібліотеки, які необхідні тільки виконуваних файлів, розташованим в / usr (таким, як виконавчі файли X Window). Зокрема, бібліотека libm.so. * може бути розташована в / usr / lib, якщо вона не потрібна ніяким програмами з / bin або / sbin. Може існувати більше одного варіанта каталогу / lib в системах, що підтримують більш одного формату виконуваних файлів (наприклад, 32-розрядні і 64-розрядні формати), при цьому для кожного формату потрібен свій окремий варіант поділюваних бібліотек (які можуть називатися / lib32 і / lib64 ).
/ Mnt призначений для тимчасового монтування файлових систем у міру необхідності. Вміст цього каталогу індивідуально для кожної системи і не повинно жодним чином впливати на роботу програм, що запускаються.
/ Opt резервується стандартом FHS для встановлення додаткових програмних пакетів. Передбачається, що будь-який такий пакет повинен розміщувати свої статичні файли в окремій структурі / opt /, де - назва пакета. Виконувані програми розташовуються в каталозі / opt / / bin, а в / opt / / man розміщуються сторінки звичайного для Unix інтерактивного керівництва man. Файли пакета, які є змінними (змінюваними при виконанні стандартних операцій), повинні встановлюватися в / var / opt, а специфічні для хоста конфігураційні дані повинні встановлюватися в / etc / opt. Ніякі файли пакету не повинні розміщуватися поза каталогів / opt, / var / opt та / etc / opt, крім тих файлів, які повинні виявитися в інших місцях з тієї причини, що інакше пакет не зможе функціонувати нормально. Наприклад, файли блокування пристроїв повинні розташовуватися в / var / lock, а файли пристроїв повинні розташовуватися в / dev.
/ Root - домашній каталог суперкористувача. Рекомендоване місце його розташування - коренева файлова система. В FHS підкреслюється, що обліковий запис суперкористувача повинна використовуватися виключно для системного адміністрування і його не рекомендується витрачати для виконання завдань, які можуть бути виконані непривілейованим користувачем. З цієї причини не варто розміщувати в root підкаталоги для пошти та інших програм. Пошта для таких адміністраторських ролей, як root, postmaster і webmaster повинна пересилатися відповідним користувачеві.
/ Sbin містить утиліти для виконання завдань системного адміністрування (і інші команди, які використовуються тільки користувачем root). Цей каталог містить виконувані файли, необхідні для завантаження системи і її відновлення в різних ситуаціях (restoring, recovering, and / or repairing the system), що не потрапили в каталог / bin. Єдина команда, яка обов'язково повинна бути присутня в / sbin, - shutdown. Наприклад, команда ping, хоча вона абсолютно необхідна надкористувачу, часто використовується і рядовими користувачами, і з цієї причини повинна розміщуватися в / bin. Автори стандарту рекомендують надати всім користувачам право на читання і виконання для всіх файлів, розташованих в / sbin, крім, може бути тих програм, для яких встановлені біти setuid і setgid. Поділ каталогів / bin і / sbin робиться з метою встановлення явної відмінності між виконуваними файлами, які використовуються усіма, і тими утилітами, які в основному використовуються для вирішення адміністративних завдань. З точки зору безпеки немає ніяких переваг в тому, щоб зробити / sbin недоступним для користувачів.
Каталог / tmp призначений для зберігання тимчасових файлів, створюваних у процесі роботи різних програм. Рекомендується видаляти всі файли і каталоги в / tmp при кожному завантаженні системи.
Для збереження сумісності зі старими системами (до тих пір, поки всі реалізації не почнуть використовувати каталоги, розміщені безпосередньо в / var) можуть створюватись такі символічні посилання:
/ Usr / spool -> / var / spool
/ Usr / tmp -> / var / tmp
/ Usr / spool / locks -> / var / lock
Каталог / usr / local використовується для встановлення програм, які будуть використовуватися локально в рамках даного хоста. Він може використовуватися для програм і даних, що не потрапили в каталог / usr, доступ до яких дозволено з інших хостів. Цей каталог не повинен перезаписуватися при оновленнях системного програмного забезпечення. Оскільки в цей каталог встановлюються програмні пакети, в ньому створюється структура підкаталогів, аналогічна структурі кореневого каталогу та каталогу / usr.
/ Usr / share містить всі файли, які призначені тільки для читання і не залежать від архітектури. Скажімо, комп'ютери на платформах i386, Alpha і PowerPC можуть підтримувати один загальний каталог / usr / share, який монтується на інших комп'ютерах. Прикладами файлів, що містяться у цьому каталозі, можуть служити файли документації (man, doc) або бази даних (dict, terminfo, zoneinfo). Будь-яка програма або пакет, який містить або вимагає даних, що не підлягають модифікації, повинні зберігати ці дані в каталозі / usr / share (або / usr / local / share, якщо пакет встановити локально). У каталозі / usr / share створюються такі підкаталоги або символічні посилання:
man - інтерактивні керівництва;
misc - різні архітектурно-незалежні дані, для яких не потрібен окремий підкаталог в / usr / share;
dict - словники (факультативно), зазвичай тут знаходиться тільки файл words для англійської мови, який використовується утилітою look і різними програмами перевірки правопису; списки слів для інших мов можуть бути додані, використовуючи англійська назва відповідної мови, наприклад, / usr / share / dict / french, / usr / share / dict / danish і т.д.;
doc - різна документація (факультативно);
games - файли статичних даних для / usr / games (факультативно);
info - основний каталог для системи GNU Info (факультативно);
locale - локальна інформація (факультативно);
nls - каталоги повідомлень для підтримки мов (факультативно);
sgml - дані для SGML і XML (факультативно);
terminfo - каталог бази даних для terminfo (факультативно);
tmac - макроси для troff (факультативно);
zoneinfo - конфігураційні файли і інформація про тимчасову зоні (факультативно).
Дані ігрових програм, які зберігаються в / usr / share / games, повинні бути статичними. Будь-які модифікуються файли, такі як файли з протоколами і результатами ігор, повинні розміщуватися в каталозі / var / games.
Як відомо, сторінки інтерактивного керівництва man традиційно розбиті на секції. Для кожної секції створюється окремий каталог з ім'ям / / manN /, де - вказівка на архітектуру (наприклад, i386), а рядок визначає мову, країну і кодування і має наступний формат:
[_][.][,].
Каталог / var містить файли зі змінними даними: каталоги і файли черг, дані про адміністрування, тимчасові файли. Деякі частини каталоговій структури / var не є розділяються між різними системами. До них відносяться / var / log, / var / lock та / var / run. Інші частини можуть бути розділяються, наприклад, / var / mail, / var / cache / man, / var / cache / fonts і / var / spool / news. Структура каталогів / var визначається в стандарті FHS з тією метою, щоб зробити можливим монтування каталогу / usr в режимі тільки для читання. Все, що записується на диск у процесі виконання системних операцій (на противагу процесам установки і підтримки програм), має розміщуватися в каталозі / var. Кілька підкаталогів «зарезервовані» - вони не повинні використовуватися довільним чином, оскільки це суперечить практиці, що склалася: / var / backups, / var / cron, / var / msgs,
/ Var / divserve.
Додатки в загальному випадку не повинні додавати каталоги безпосередньо в / var. Такі каталоги мають створюватися у відповідних підкаталогах. Каталог / var / cache призначений для кешування даних додатками. На відміну від / var / spool, кешовані файли можуть бути видалені без втрати даних. Але ці дані повинні зберігатися між сеансами роботи програми та при перезагрузках системи. Додаток повинен завжди мати можливість продовжити роботу, навіть після видалення цих файлів адміністратором (наприклад, при нестачі дискового простору). Існування окремого каталогу для Кешована даних дозволяє системним адміністраторам встановлювати для цього каталогу правила користування і резервного копіювання, що відрізняються від правил, що встановлюються для інших каталогів в / var. Зазвичай в цьому каталозі створюються підкаталоги fonts (локально згенеровані шрифти), man (локально відформатовані сторінки керівництва), www (кеш даних для WWW-проксі), (кешованим дані пакета). / Var / cache / man передбачений для сайтів, в яких файлова система / usr монтується тільки на читання, але в них допускається створення сторінок керівництва, відформатованих локально. Сайти, в яких / usr монтується з правом запису (наприклад, коли у системи всього один користувач) можуть не створювати каталогу / var / cache / man, а використовувати замість нього каталоги cat безпосередньо в / usr / share / man.
Файли блокування пристроїв та інших ресурсів, що використовуються багатьма додатками, такі як файли блокування послідовних портів, повинні зберігатися в каталозі / var / lock. Назви цих файлів повинні формуватися відповідно до угоди, згідно з яким використовується префікс «LCK ..», за яким слід базове ім'я пристрою. Файли блокування в / var / lock повинні бути всім доступні з читання.
Каталог / var / log містить різноманітні файли протоколів: lastlog (запис про останній вході в систему кожного користувача); messages (системні повідомлення від syslogd); wtmp (записи про всіх входах і виходах користувачів у систему).
Область спулінга для пошти повинна розміщуватися в каталозі / var / mail, а імена файлів з повідомленнями повинні мати вигляд. Файли поштових скриньок в цих каталогах повинні зберігатися у форматі стандартних поштових скриньок Unix.
Змінні дані для пакетів, встановлених в / opt, повинні розміщуватися в / var / opt /, де - назва структури каталогів в / opt, в якій зберігаються статичні дані додаткового пакету ПЗ, виключаючи ті випадки, коли розміщення явно вказано в будь-якому файлі з / etc. На внутрішню структуру каталогу / var / opt / ніяких обмежень не накладається.
Каталог / var / run містить дані, що описують стан системи з моменту її завантаження. Програми можуть мати підкаталоги в каталозі / var / run, тим більше, якщо вони використовують більше одного файлу часу виконання. У цьому каталозі повинні бути, зокрема, розміщені файли з ідентифікаторами запущених процесів (PID). Угода про імена цих файлів наступне:. Pid. Вміст PID-файлу являє собою ідентифікатор процесу в коді ASCII, записаний у десятковій нотації, за яким слідує символ кінця рядка. Наприклад, якщо crond запущений як процес з номером 25, / var / run / crond.pid буде містити три символи: два, п'ять і символ нового рядка. В / var / run розташований також файл utmp, в якому зберігається інформація про те, хто в даний момент використовує систему. Непривілейованих користувачі повинні бути позбавлені права на запис до теки / var / run.
Каталог / var / spool містить дані, які очікують будь-якої подальшої обробки: підкаталоги lpd (спулінг для принтера), mqueue (черга вихідної пошти), news (спулінг новин), uucp (спулінг для UUCP) і т.п.
Каталог / var / tmp використовується програмами, яким потрібно тимчасові файли чи каталоги для зберігання даних, які зберігаються між перезавантаженнями системи.
Ієрархія файлових систем
У кореневій файловій системі повинна знаходитися інформація для завантажувача й основні файли, необхідні в процесі старту системи (наприклад, ядро). Тут же повинні розміщуватися файли конфігурації і все, що необхідно для монтування інших файлових систем, включаючи такі утиліти, як mount. Щоб забезпечити можливість відновлення системи після збоїв, в кореневій файловій системі повинні бути присутні всі утиліти, потрібні адміністратору для діагностування проблем і реконструкції системи після будь-якої аварійної ситуації. Тут же повинні бути розташовані і ті утиліти, які необхідні для відновлення даних з резервних копій.
По ряду причин розмір кореневої файлової системи бажано зробити досить малим.
Іноді доводиться монтувати кореневу файлову систему з носія малого обсягу.
Коренева файлова система зазвичай містить неподільні файли, специфічні для конкретної системи. Спільні файли можна розмістити на мережевих дисках. Це дозволяє використовувати в якості робочих станцій у мережі комп'ютери з маленькими за обсягом локальними жорсткими дисками.
Маленька коренева файлова система менш схильна до руйнування у випадку збоїв.
З стандарту можна зробити висновок про те, що в кореневій файловій системі обов'язково повинні цілком розташовуватися каталоги / bin, / dev, / etc, / lib, / sbin і, можливо, / root.
Каталог / boot в силу апаратних обмежень може виявитися необхідним розмістити на окремому розділі диску, розташованому цілком в межах перших 1024 циліндрів завантажувального диска.
Решта підкаталоги кореневого каталогу (home, mnt, opt, tmp, usr, var) можуть розміщуватися в інших файлових системах (на інших розділах або дисках). Більш того, в стандарті явно постулюється, що в каталогах / usr, / opt та / var розміщуються такі файли, які можуть розташовуватися в інших розділах диска або в інших файлових системах. Розробники стандарту радять у тому випадку, коли / var не може бути розміщений в окремому розділі диску, перемістити каталог / var з кореневого розділу в розділ із каталогом / usr. Однако / var не можна робити посиланням на / usr тому що це ускладнює поділ / usr і / var і може призвести до конфлікту імен, краще вже зробити / var посиланням на / usr / var.
Відзначимо, що в статті мова йде тільки про вимоги та рекомендації стандарту FHS, розробленого з орієнтацією на операційні системи Linux і BSD. Навіть конкретні дистрибутиви Linux не в усьому дотримуються цього стандарту. Так, в Red Hat Linux версій 7.3 та 8.0 каталог / etc / opt хоча і створений, але порожній, а конфігураційні каталоги пакетів розміщуються безпосередньо в / etc. Можна вказати і інші відхилення від стандарту. Але все ж в основному структура каталогів витримується відповідно до FHS, так що знайомство з цим стандартом, безумовно, корисно всім користувачам Linux, а тим більше розробникам.