3. Кореневий каталог

Цей розділ розповідає про структуру кореневого (root) каталогу. Наповнення кореневої файлової системи має бути достатнім для завантаження, відновлення, відбудови та/або ремонту системи.:

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

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

• Вона часом монтується з дуже обмежених носіїв
• Коренева файлова система містить багато специфічних для системи файлів налаштувань. Можливе розміщення там ядра для конкретної системи, назви конкретної системи і т. і. Це значить, що коренева файлова система, зазвичай, не узагальнюється між машинами в мережі. Утримуючи її малого розміру на сервері в мережі, ви зберігаєте більше місця для загальних файлів. Це дозволяє також використовувати робочі станції з меньшими жорсткими дисками.
• Хоча у вас коренева файлова система може знаходитися на великому розділі і заповнена на ваш смак, завжди є люди з маленькими розділами. Коли ви маєте більше встановлених файлів, ви можете стикнутися з випадками несумісності з системами, що використовують кореневу файлову систему на малому розділі. Якщо ви розробник, то ви можете перетворити свої уподобання на проблему для великої кількості людей.
• Помилки роюоти диску, що нищать данні на кореневій файловій системі є значно більшою проблемою ніж помилки на всіх інших системах. Мала коренева файлова система меньше схильна до пощкоджень через аварії системи.

Програмне забезпечення не повинно створювати або потребувати спеціальних файлів чи каталогів в кореневому каталозі. Інші місця в СПФС структурі забезпечують більш ніж достатньо гнучкості для будь-якого пакету.

Початок обгрунтування

Є декілька резонів, чому створення нового підкаталогу в кореневій файловій системі забороняється:

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

Закінчено обгрунтування

/-- кореневий каталог
|- bin		Важливі двійкові командні файли
|- boot		Постійні файли для завантаження системи
|- dev		Файли пристроїв
|- etc		Власні файли налаштувань системи
|- home		"Домашні" каталоги користувачів
|- lib		Важливі загальні бібліотеки та модулі ядра
|- mnt		Точки монтування для додаткових файлових систем
|- opt		Додаткові пакети програм
|- root		"Домашній" каталог керуючого системою
|- sbin		Важливі системні двійкові файли
|- tmp		Тимчасові файли
|- usr		Вторинна структура
|- var		Змінні данні

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

Ядро операційної системи має знаходитися або в / або в /boot. Додаткові відомості відносно розташування ядра можно знайти нижче, в пункті про /boot, .

3.1 /bin: Важливі двійкові командні файли користувача (для всіх користувачів)

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

В межах /bin не повинно бути підкаталогів.

Двійкові команди, що не достатньо важливі для розміщення в /bin мають бути натомість розташовані в /usr/bin. Команди, що потрібні тільки звичайним користувачам (X Window System, chsh і т.і.), зазвичай, не достатньо важливі для розміщення в кореневому розділі.

Необхідні для /bin файли:

• Загальні команди:

  Наступні команди мають знаходитися тут через їх виняткову важливість, виключаючи декілька, що знаходяться тут з історичних причин.

  {cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, ed, false, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, setserial, sh, stty, su, sync, true, umount, uname}

  Коли /bin/sh є Bash, /bin/sh має бути символічним або жорстким зв'язком до /bin/bash оскільки Bash поводиться інакше коли викликається як sh а не bash. pdksh, що може бути /bin/sh на диску встановлення, має так само бути обіграним через символічний зв'язок з /bin/sh до /bin/ksh. Використання символічного зв'язку в цьому випадку дозволить користувачам легко побачити, що /bin/sh не є справжньою оболонкою Борна.

  Фактичне стандартне місце розташування C-shell - /bin/csh. Оболонка С або рівнозначна (така як tcsh), коли вона доступна в системі, має розміщуватися в /bin/csh. /bin/csh може бути символічним зв'язком до /bin/tcsh або /usr/bin/tcsh.

  Примітка: Команди [ та test вбудовані в більшість часто використованих оболонок замінників оболонки Борна (/bin/sh). Ці дві команди не повинні розміщуватися в /bin, вони можуть бути розташовані в /usr/bin. Вони повинні знаходитися як двійкові файли в любій Unix або Unix подібній системі для забезбечення узгодженості з стандартом POSIX.2.

• Команди для відновлення:

  Ці команди додано щоб зробити можливим відновлення системи (за умови, що / не ушкоджено).

  {tar, gzip, gunzip (зв'язка до gzip), zcat (зв'язка до gzip)}

  Коли резервування системи виконувалося не з gzip чи tar, в кореневому каталозі треба розмістити мінімально необхідний набір засобів відновлення. Наприклад, багато систем повинні мати cpio, оскільки це другий за вжитком після tar інструмент резервування.

  Відповідно, коли ви не збираєтесь ніколи відновлювати систему з кореневого каталогу, то ці команди можуть виключатися (наприклад, кореневий розділ записано на мікросхему пам'яті, /usr монтується через NFS) Коли відновлення системи планується через мережу, то ftp чи tftp (разом з усім необхідним для забезпечення з'єднання) має бути доступним на кореневому розділі.

  Не дуже суттєві команди відновлення можуть знаходитися або в /bin або в /usr/bin на різних системах.

• Команди для мережи:

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

  { domainname, hostname, netstat, ping }

3.2 /boot: Постійні файли завантажувача системи

Цей каталог містить все необхідне для процесу завантаження, за виключенням файлів налаштувань та встановлювача мапи. Таким чином, /boot зберігає данні, що використовуються до того як ядро почне виконувати програми режиму користувача. Це можуть бути: збережений сектор початкового завантаження, файли мап секторів та інші данні, що не редагуються вручну. Програми, необхідні для налаштування процесу завантаження, мають бути в /sbin. Файли налаштувань, для початкових завантажувачів, мають бути в /etc.

Ядро операційної системи може бути або в / або в /boot.

Примітка: На деяких 386 машинах, може бути необхідним розташувати /boot на окремому розділі в межах нижче 1024 циліндру пристрою завантаження, що пов'язано з обмеженнями апаратних засобів.

Деякі MIPS системи потребують щоб /boot монтувався як файлова система MS-DOS або якась інша файлова система, що підтримується вбудованими програмами. Це може накладати обмеження на можливі назви файлів в/boot (тільки для відповідних систем).

3.3 /dev: Файли пристроїв

Каталог /dev - місце для розташування спеціальних файлів та файлів пристроїв.

Коли можливо, щоб пристрої створювалися в /dev вручну, в /dev повинна знаходитися команда MAKEDEV, яка може створювати пристрої за потребою. В ньому може бути також MAKEDEV.local, для будь-яких місцевих пристроїв.

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

3.4 /etc: Налаштування для конкретної системи

/etc містить файли налаштувань та каталоги, що є особливими для певної системи.

В структурі /etc не повинно бути двійкових файлів.

/etc -- Налаштування для конкретної системи
|-X11	Налаштування для X Window System
|-opt	Налаштування для /opt

Наступний розділ частково призначено щоб висвітити опис змісту /etc разом з прикладами, це не є вичерпний перелік.

Необхідні для /etc файли:

• Файли загального значення:

  { adjtime, csh.login, disktab, fdprm, fstab, gettydefs, group, inittab, confissue, ld.so.conf, lilo.conf, motd, mtab, mtools, passwd, profile, securetty, shells, syslog.conf, ttytype }

• Мережеві файли:

{ exports, ftpusers, gateways, host.conf, hosts, hosts.allow, hosts.deny, hosts.equiv, hosts.lpd, inetd.conf, networks, printcap, protocols, resolv.conf, rpc, services }

Примітка:

Встановлення командного сценарію, що потрібен під час завантаження, може наслідувати System V або BSD моделі. Подальші визначення в цій області можуть бути додані до майбутніх версій цього стандарту.

Системи, що використовують тіньові паролі, будуть мати додаткові файли налаштувань в /etc(/etc/shadow та інші) та програми в /usr/sbin(useradd, usermod та інші).

3.4.1 /etc/X11: Налаштування для X Window System

/etc/X11 - це рекомендоване місце для всіх налаштувань певної машини, що стосуються X11. Цей каталог потрібний щоб дозволити місцеве керування коли /usr змонтовано тільки на читання. Файли, що повинні знаходитися в цьому каталозі - Xconfig (та/або XF86Config) та Xmodmap.

Підкаталоги /etc/X11 можуть містити такі для xdm та для будь-яких інших програм (деякі розпорядники вікон, наприклад), що їх потребують. Ми рекомендуємо щоб розпорядники вікон з єдиним файлом налаштунків, що стандартно є файл .*wmrc називали його system.*wmrc (коли не існує іншої загально визнаної назви) і не використовували підкаталоги. Будь-які підкаталоги розпорядників вікон повинні мати назви, що співпадають з назвою двійкового файлу розпорядника вікон.

/etc/X11/xdm зберігає файли налаштувань для xdm. Більшість файлів, що звичайно зберігається в /usr/lib/X11/xdm. Деякі змінні данні для xdm зберігаються в /var/lib/xdm.

3.4.2 /etc/opt: Файли налаштувань для /opt

Файли налаштувань для додаткових програм, що стосуються тільки цієї машини, повинні встановлюватися в межах підкаталогу /etc/opt/<package>, де <package> - назва піддерева в /opt в якому встановлено постійні данні цього пакету. Не встановлено правил на внутрішню організацію /etc/opt/<package>.

Коли файл налаштування повинен розміщуватися в іншому місці, щоб забезпечити роботу пакету або системи, він може бути розташований не в /etc/opt/<package>.

Початок обгрунтування

Дивіться обгрунтування для /opt.

Закінчено обгрунтування

3.5 /home: Каталоги користувачів (за потребою)

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

На невеликих системах, каталог кожного користувача є підкаталогом в /home як то:/home/smith, /home/torvalds, /home/operator і т.і.

На великих системах (особливо, коли /home каталоги використовуються спільно багатьма машинами через NFS) корисно розділяти домашні каталоги на групи. Групи можуть бути обрані, наприклад, такі: /home/staff, /home/guests, /home/students і т.і.

Різні люди полюбляють розташовувати рахунки користувачів в різних місцях. Отже, програма не повинна покладатися на їх певне місце знаходження. Коли вам потрібно знайти домашній каталог користувача, треба використовувати бібліотеку getpwent (3), а не покладатися на /etc/passwd, бо відомості про користувачів можуть зберігатися окремо з використанням таких систем як NIS.

3.6 /lib: Важливі загальні бібліотеки та модулі ядра

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

/lib --		важливі спільні бібліотеки та модулі ядра
|-- modules	модулі ядра для завантаження

Тут розміщено /lib/lib.so.*, /lib/libm.so.*, загальний динамічний зв'язувач /lib/ld.so та інші загальні бібліотеки, що потрібні двійковим з /bin та /sbin.

Загальним бібліотекам, що необхідні тільки двійковим з /usr (таким як всі двійкові X Window), не місце в /lib. Тут мають бути загальні бібліотеки, що необхідні для запуску двійкових тільки з /bin та /sbin. Бібліотеку libm.so.* можна помістити в /usr/lib коли вона не потрібна ні для чого з /bin та /sbin.

З міркувань сумісності, /lib/cpp повинно існувати як посилання на C допроцесор встановлений в системі. Звичайно, місце для нього /usr/lib/gcc-lib/<target>/<version>/cpp. /lib/cpp може вказувати на цей файл або на будьяке посилання на цей файл, що є в файловій системі. (Наприклад, /usr/bin/cpp також часто використовується).

Визначення для /lib/modules буде в майбутньому

3.7 /mnt: Точка монтування для файлових систем, що їх монтують тимчасово

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

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

3.8 /opt: Додаткові прикладні програмні пакети

/opt --		Додаткові прикладні програмні пакети
|-- <package>	Постійні об'єкти пакета

/opt зарезервовано для встановлення додаткових прикладних програмних пакетів.

Пакет, що встановлюється в /opt, має розмістити власні постійні файли в окремому дереві каталогів/opt/<package>, де <package> - назва, що описує програмний пакет.

Програми, що викликаються користувачами, повинні розміщуватися в каталозі /opt/<package>/bin. Коли пакет має сторінки допомоги для UNIX, вони повинні розміщуватися в /opt/<package>/man з використанням тієї ж структури як в /usr/share/man.

Каталоги /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib та /opt/man зарезервовані для використання місцевим наглядачем за системою. Пакети можуть мати "лицьові" файли призначені для розміщення в (копіюванням чи встановленням зв'язків) ці зарезервовані каталоги місцевим наглядачем за системою, але вони повинні працювати нормально і за відсутності цих каталогів.

Файли пакетів, що змінюються під час роботи пакету повинні бути встановлені в /var/opt. Дивись текст для /var/opt за додатковими поясненнями.

Файли налаштувань для конкретної системи повинні розміщуватися в /etc/opt. Дивись текст для /etc за додатковими поясненнями.

Файли пакету не повинні розміщуватися за межами /opt, /var/opt та /etc/opt структур виключаючи ті файли пакету, що мають знаходитися в певних місцях файлової системи для її вірного функціонування. Наприклад, файли контролю пристроїв повинні знаходитися в /var/lock і пристрої повинні бути в /dev.

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

Початок обгрунтування

Використання /opt для додаткового програмного забезпечення є добре відомою практикою в співтоваристві UNIX. System V Applicatoin Binary Interface [AT&T 1990], що базується на System V Interface Definition (третя редакція), подає для /opt структуру дуже близьку до визначеної тут.

Intel Binary Compatibility Standard v.2 (iBCS2) також подає схожу структуру для /opt.

Зазвичай, всі данні, що необхідні для підтримки пакету в системі, повинні знаходитися в межах /opt/<package>, включаючи файли, що їх треба копіювати в /etc/opt/<package> та /var/opt/<package> так само як з резервованих каталогів в /opt.

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

Закінчено обгрунтування

3.9 /root: Домашній каталог для наглядача за системою (root user), за бажанням

/ - традиційно є домашнім каталогом для рахунку root в UNIX системах. /root використовується на багатьох Linux та деяких UNIX системах (для зменшення метушні в каталозі /). Домашній каталог для рахунку root може бути визначеним розробником або місцевими уподобаннями. Можливі варіанти включають /, /root, та /home/root.

Коли домашній каталог для рахунку наглядача не розміщений на кореневому розділі, то необхідно виконати щоб стандартно таким призначався /, якщо його неможливо знайти.

Зауважимо: Ми заперечуємо проти використання рахунку наглядача для таких світських справ як новини та листи та рекомендуємо використовувати його тільки для керування системою. З цих міркувань, ми рекомендуємо щоб такі підкаталоги як Mail та News не з'являлися в каталозі наглядача, а листи для тих хто виконує обов'язки наглядача, керуючого поштою та майстра павутини скеровувалися відповідним користувачам.

3.10 Системні двійкові (двійкові, що лише потрібні в /etc)

Засоби, що потрібні для керування системою (та інші команди тільки для наглядача), зберігаються в /sbin, /usr/sbin та /usr/local/sbin. В /sbin, звичайно, розміщують додатково до двійкових в /bin двійкові, що важливі для завантаження системи. Все, що буде виконуватися після того як змонтовано /usr (коли з цим немає проблем), має бути розташовано в /usr/sbin. Двійкові, що потрібні тільки місцевому наглядачу, повинні знаходитися в /usr/local/sbin.

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

Зауважимо: Наприклад, файли, такі як chfn, що їх користувач запускає тільки час від часу, всеж таки повинні знаходитися в /usr/bin. ping, напроти, дуже потрібний наглядачу (відновлення роботи мережи та її перевірка) часто використовується користувачами і повинен, зважаючи на це, жити в /bin.

Ми рекомендуємо щоб користувачі мали можливість читати та виконувати все, що знаходиться в /sbin, виключаючи, звичайно, програми setuid та setgid. Розмежування між /bin та /sbin було зроблено не з міркувань безпеки або заборони користувачу дивитись операційну систему, а лише щоб забезпечити краще розмежування між двійковими для загального користування та призначиними лише для нагляду за системою. Не існує ніяких переваг безпеки, якщо зробити /sbin закритим для користувачів.

Файли необхідні для /sbin:

• Загальні команди:

  { hwclock, getty, init, update, mkswap, swapon, swapoff }

• Команди виключення:

  { fastboot, fasthalt, halt, reboot, shutdown }
  (Або будьякі їх комбінації, поки shutdown присутня.)

• Команди керування файловою системою:

  { fdisk, fsck, fsck.*, mkfs, mkfs.* }
* = одна або більше ext, ext2, minix, msdos, xia та можливо інші

• Команди мережи:

  { ifconfig, route }

3.11 /tmp: Тимчасові файли

Каталог /tmp повинен бути доступним для програм, що потребують тимчасових файлів.

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

Пргограми не повинні очікувати, що файли або каталоги в /tmp будуть збережені між викликами програми.

Початок обгрунтування

Стандарт IEEE P1003.2(POSIX, частина 2) ставить подібні вимоги.

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

Закінчено обгрунтування

Перекладено А. М. Добровольським © 2000 р.

Вперед

Що де є

Назад