Filesystem Hierarchy Standard Group
Перевод на русский язык - В.А.Костромин, январь 2003 г.
(Смотри предисловие переводчика).
Оригинал перевода: http://linux-ve.net/MyLDP/file-sys/fhs-2.2-rus/
Abstract
Настоящий стандарт состоит из набора требований и рекомендаций по размещению файлов и каталогов для UNIX-подобных операционных систем. Целью этих рекомендаций является обеспечение совместимости приложений и различных скриптов, средств системного администрирования и разработки, а также достижение единообразия в документации на разные системы.
Все торговые знаки и авторские права принадлежат их обладателям, если только специально не оговорено противное. Использование термина в этом документе не должно расцениваться как покушение на какой-либо торговый знак или фирменные знаки (Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark).
Copyright й 2001 Paul `Rusty' Russell
Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder.
Этот стандарт необходим для того, чтобы:
Мы достигаем этих целей тем, что
Настоящий стандарт используется для того, чтобы
Мы рекомендуем вам читать версию этого документа, набранную с использованием различных шрифтов, а не простой текстовый вариант. В версии, использующей различные шрифты, имена файлов и каталогов набраны шрифтом фиксированной ширины.
Компоненты имен файлов, которые могут изменяться, представляются описанием соответствующего компонента, заключенным угловые скобки "<" и ">", <вот так>. Адреса электронной почты тоже заключаются в "<" и ">", но они изображаются обычным шрифтом.
Необязательные компоненты имен файлов заключаются квадратные скобки "[" и "]", причем оба этих условных обозначения могут комбинироваться. Например, если имя файла может иметь расширение или не иметь такового, это представляется следующим образом: <filename>[.<extension>].
Произвольная подстрока в имени каталога или файла обозначается символом "*".
В настоящем стандарте предполагается, что операционная система, использующая FHS-совместимую файловую систему, поддерживает обычные для большинства UNIX-систем средства обеспечения безопасности (the same basic security features found in most UNIX filesystems).
Можно определить два независимых критерия разбиения множества файлов на независимые типы (прим.переводчика: математик сказал бы - на непересекающиеся подмножества): разделяемые файлы в противоположность неразделяемым и неизменяемые (статические) файлы как противоположность изменяемым файлам.
Разделяемые данные - это те, к которым может быть разрешен доступ с различных хостов; неразделяемые - те, которые являются специфическими для данного хоста. Например, домашние каталоги пользователей содержат разделяемые данные, а файлы блокирования устройств (device lock files) являются неразделяемыми.
Неизменяемые (или статические) данные - это исполняемые файлы, библиотеки, документация, и все, что не должно изменяться без вмешательства системного администратора; изменяемые данные - это все, что может изменяться без участия системного администратора.
Должно существовать простое и понятное соответствие между каталогами и типом данных, которые в этом каталоге размещаются: каталоги могут являться точками монтирования для других файловых систем, характеристики которых отличаются от характеристик той файловой системы, в которую они монтируются.
Выделение "разделяемых" данных может использоваться, например, для:
Различие между "статическими" и "изменяемыми" данными оказывает влияние на структуру файловой системы по двум основным направлениям:
Приведем пример того, как должны распределяться данные для того, чтобы файловая система могла считаться совместимой со стандартом FHS (еще раз повторим, что это только пример, можно привести и другие примеры того, как размещать данные для обеспечения FHS-совместимости).
| Разделяемые | Неразделяемые | |
| Статические | /usr | /etc |
| /opt | /boot | |
| Изменяемые | /var/mail | /var/run |
| /var/spool/news | /var/lock | |
Таблица 2.1
В противовес изложенным соображениям, в силу которых очень многое требуется разместить в корневой каталоговой системе, стоит подумать о том, чтобы поддерживать размер корневой файловой системы настолько малым, насколько это только возможно. Желание сохранить размер корневой файловой системы разумно малым возникает по нескольким причинам:
Программы или приложения никогда не должны создавать или предполагать наличие каких-то файлов или подкаталогов в корневой директории. Другие области файловой иерархии FHS предоставляют более чем достаточно места для любого пакета.
Существует несколько причин, по которым создание нового подкаталога в корневой файловой системе запрещено:
[12] Обычно это используется для поддержки 64-битного или 32-битного формата в системах, поддерживающих несколько форматов исполняемых файлов, и требующих библиотек с одним и тем же названием. В этом случае /lib32 и /lib64 могут быть библиотечными каталогами, а /lib - символической ссылкой на один из них.
[13] Наличие /lib<qual>/cpp все же допускается: тем самым допускаются случаи, когда /lib и /lib<qual> есть фактически одно и то же (один из них является символической ссылкой на другой).
Этот каталог не должен использоваться программами инсталляции: для создания и хранения временных файлов на этапе инсталляции ПО должны использоваться временные каталоги, не используемые системой.
Пакет, который устанавливается в каталог /opt, должен размещать свои статические файлы в отдельной каталоговой структуре /opt/<package>, где <package> - название соответствующего пакета программного обеспечения.
|
"/opt" <package> |
"Дополнительные пакеты программного обеспечения" Статические объекты пакета |
Дерево 3.12.2.1
Каталоги /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib и /opt/man зарезервированы для использования локальным системным администратором. Пакеты могут предоставлять "front-end" файлы, которые локальный системный администратор может разместить в этих зарезервированных каталогах (либо путем копирования, либо установив ссылку), но любой пакет должен нормально функционировать и в случае отсутствия этих зарезервированных директорий.
Программы, вызываемые на исполнение пользователем, должны располагаться в каталоге /opt/<package>/bin. Если пакет ПО содержит в своем составе страницы обычного в UNIX интерактивного руководства man, они должны устанавливаться в каталог /opt/<package>/man, который должен иметь такую же структуру, как и каталог /usr/share/man.
Файлы пакета, которые являются переменными (изменяемыми при выполнении стандартных операций), должны устанавливаться в /var/opt. Дополнительную информацию ищите в разделе о каталоге /var/opt.
Специфичные для хоста конфигурационные данные должны устанавливаться в /etc/opt. Дополнительную информацию ищите в разделе о каталоге /etc.
Никакие файлы пакета не должны размещаться вне каталогов /opt, /var/opt и /etc/opt, кроме тех файлов, которые должны оказаться в других местах по той причине, что иначе пакет не сможет функционировать нормально. Например, файлы блокирования устройств должны располагаться в /var/lock, а файлы устройств должны располагаться в /dev.
Дистрибутивы могут устанавливать программное обеспечение в каталог /opt, но не должны модифицировать или удалять ПО, установленное местным системным администратором, без разрешения этого самого администратора.
Стандарт Intel Binary Compatibility Standard v. 2 (iBCS2) тоже предполагает подобную структуру для /opt.
Как правило все данные, необходимые для поддержки функционирования пакета, должны присутствовать в каталоге /opt/<package>, включая файлы, копируемые в /etc/opt/<package> и /var/opt/<package> а также специально создаваемые для пакета каталоги в /opt.
Небольшие ограничения на дистрибутивы, использующие /opt,
необходимы из-за возможности возникновения конфликтов между
ПО, устанавливаемым из дистрибутива, и локально устанавливаемого ПО,
особенно в том случае, когда бинарные пакеты используют фиксированные
имена каталогов и файлов.
[14]
Если домашний каталог суперпользователя расположен не в корневом разделе
диска, необходимо убедиться, что если он не будет найден, то по умолчанию
таковым будет назначен каталог /. (Примечание переводчика.
Я не совсем уверен, что вышеприведенное предложение является правильным переводом
следующего текста: "If the home directory of the root account is not stored on the root
partition it will be necessary to make certain it will default to
/ if it can not be located.")
Мы не рекомендуем использовать бюджет пользователя root для выполнения
задач, которые могут быть выполнены непривилегированным пользователем.
Бюджет суперпользователя должен использоваться исключительно для
системного администрирования. По этой причине мы не рекомендуем
размещать подкаталоги для почты и других приложений в домашнем каталоге
пользователя root. Почта для таких администраторских ролей как root,
postmaster и webmaster должна пересылаться соответствующему пользователю.
| shutdown | Команда остановки системы. |
Таблица 3.14.2.1
| fastboot | Команда перезагрузки системы без проверки дисков (optional) |
| fasthalt | Команда остановки системы без проверки дисков (optional) |
| fdisk | Программа переразбиения диска (optional) |
| fsck | Утилита для проверки и восстановления файловых систем (optional) |
| fsck.* | Утилиты для проверки и восстановления отдельных типов файловых систем (optional) |
| getty | Программа getty (optional) |
| halt | Команда остановки системы (optional) |
| ifconfig | Утилита конфигурирования сетевых интерфейсов (optional) |
| init | Первоначальный процесс (optional) |
| mkfs | Команда создания файловой системы (optional) |
| mkfs.* | Команда создания файловой системы конкретного типа (optional) |
| mkswap | Команда создания файла или раздела подкачки (swap-раздела) (optional) |
| reboot | Команда перезагрузки системы (optional) |
| route | Утилита определения таблицы статической IP-маршрутизации (optional) |
| swapon | Утилита подключения механизма свопинга (optional) |
| swapoff | Утилита отключения свопинга (optional) |
| update | Демон периодической очистки системных буферов (optional) |
Таблица 3.14.3.2
[15] Когда-то исполняемые файлы, размещаемые теперь в /sbin, помещались в /etc. Программы, которые выполняются после того, когда смонтирован каталог /usr (если монтирование прошло без проблем) обычно размещаются в /usr/sbin. Локально устанавливаемые программы для системного администрирования должны быть размещены в /usr/local/sbin. [примечание 16]
[16] Принять решение о том, какие программы
разместить в каталогах "sbin", довольно просто: если обычный
пользователь (не системный администратор) когда-либо запускает
программу, она должна размещаться в одном из каталогов "bin".
Обычные пользователи не должны указывать каталоги sbin в списке
путей, просматриваемых по умолчанию (в своей переменной PATH).
Такие, к примеру, файлы, как chfn, которые пользователи
запускают очень редко и только в особых случаях, должны, тем не менее,
размещаться в /usr/bin. Команда ping, хотя
она абсолютно необходима суперпользователю для решения задач сетевой
диагностики и восстановления сети, часто используется и рядовыми пользователями,
и по этой причине должна размещаться в /bin.
Мы рекомендуем предоставить всем пользователям право на чтение и
выполнение для всех файлов, расположенных в /sbin, кроме, может
быть тех программ, для которых установлены биты setuid и setgid.
Разделение каталогов /bin и /sbin делается не из соображений
безопасности и не для того, чтобы лишить пользователей возможности
видеть системные утилиты. Целью такого деления является установление
явного различия между исполняемыми файлами, которые используются всеми, и
теми утилитами, которые в основном используются для решения административных
задач. С точки зрения безопасности нет никаких преимуществ в том, чтобы
сделать /sbin недоступным для пользователей.
Программы не должны предполагать, что какой-либо файл в каталоге /tmp сохранится при следующем запуске программы.
Хотя данные, сохраняемые в каталоге /tmp могут удаляться по правилам, специфичным для каждого хоста, рекомендуется удалять все файлы и каталоги в /tmp при каждой загрузке системы.
FHS вводит последнюю рекомендацию на основе исторических прецедентов
и общей практики, но не считает ее обязательным требованием, поскольку
вопросы системного администрирования не являются предметом настоящего стандарта.
|
"/" bin boot dev etc lib mnt opt sbin tmp usr var |
"Корневой каталог" Основные исполняемые команды Статические файлы для загрузчика Специальные файлы устройств Специфичные для данного хоста конфигурационный данные Основные разделяемые библиотеки и модули ядра Точка монтирования для временно подключаемых файловых систем Дополнительные пакеты программного обеспечения Основные системные утилиты Временные файлы Каталоговая структура второго уровня Переменные данные |
Дерево 3.2.1
Каждый каталог из перечисленных выше подробно рассматривается далее в отдельном разделе. Каждому из каталогов /usr и /var посвящен целый раздел в этом документе в силу сложности этих каталогов.
|
"/" home lib<qual> root |
"Корневой каталог" Домашние каталоги пользователей (optional) Основные разделяемые библиотеки для альтернативных форматов (optional) Домашний каталог пользователя root (optional) |
Дерево 3.3.1
Каждый из перечисленных выше каталогов рассматривается в отдельной секции настоящего документа.
В /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 | потоковый редактор `sed' |
| sh | командная оболочка Борна |
| stty | утилита для изменения установок или вывода информации об установках терминальной линии |
| su | утилита смены идентификатора пользователя |
| sync | утилита для сброса на диск содержимого буферов кеш-памяти |
| true | утилита, не выполняющая никаких действий и возращающая статус завершения "успешно" |
| umount | утилита для размонтирования файловых систем |
| uname | утилита для получения информации о системе |
Таблица 3.4.2.1
Если /bin/sh не является настоящей оболочкой Борна, это должна быть жесткая или символическая ссылка на реальную программу оболочки.
Обе команды [ и test должны быть расположены вместе, либо в каталоге /bin, либо в /usr/bin.
Требование того, чтобы команды [ и test включались в этот каталог как отдельные исполняемые файлы (даже если они реализованы как встроенные команды оболочки) присутствует также в стандарте POSIX.2.
| csh | оболочка C-shell (optional) |
| ed | редактор `ed' (optional) |
| tar | утилита архивации tar (optional) |
| cpio | утилита архивации cpio (optional) |
| gzip | утилита сжатия (компрессии), разработанная в рамках проекта GNU (optional) |
| gunzip | утилита декомпрессии, разработанная в рамках проекта GNU (optional) |
| zcat | утилита декомпрессии, разработанная в рамках проекта GNU (optional) |
| netstat | утилита сетевой статистики (optional) |
| ping | утилита тестирования сети с помощью протокола ICMP (optional) |
Таблица 3.4.3.2
Если файлы gunzip и zcat существуют, они должны быть символическими или жесткими ссылками на gzip. /bin/csh может быть символической ссылкой либо на /bin/tcsh, либо на /usr/bin/tcsh.
Если же необходимость восстановления системы из корневого раздела
отсутствует (например, в случае загрузки бездисковых рабочих станций,
когда каталог /usr монтируется посредством протокола NFS) эти команды могут отстутствовать и в каталоге /bin.
Если восстановление системы планируется проводить по сети, то
файлы программ ftp или tftp (вместе со всем, что необходимо для
установления соединения по протоколу ftp) должны быть размещаться в корневом разделе
диска.
[1] Исполняемые файлы, которые не так важны, чтобы быть расположенными в каталоге /bin, должны размещаться в каталоге /usr/bin. Те утилиты, которые необходимы только рядовым пользователям (файлы системы X Window, chsh, и так далее) обычно не так необходимы, чтобы размещаться в корневой файловой системе (в корневом разделе диска).
[2] Программы, необходимые загрузчику для организации загрузки файлов, должны быть расположены в /sbin. Конфигурационные файлы загрузчика должны размещаться в /etc.
[3] На некоторых i386 компьютерах в силу
аппартаных ограничений может
оказаться необходимым разместить каталог /boot на отдельном разделе
диска, расположенном целиком в пределах первых 1024 цилиндров загрузочного диска.
Certain MIPS systems require a /boot partition that is a mounted
MS-DOS filesystem or whatever other filesystem type is accessible for
the firmware. This may result in restrictions with respect to usable
filenames within /boot (only for affected systems).
Если может потребоваться создавать файлы устройств в /dev вручную, каталог /dev должен содержать команду MAKEDEV, которая может создать файл устройства в случае необходимости. Он может также содержать MAKEDEV.local для любых локальных устройств.
Если требуется, MAKEDEV должен иметь возможность создания любого устройства, которое может быть установлено в системе, а не только тех устройств, которые устанавливаются при какой-либо конкретной реализации.
Следующие каталоги или символические ссылки на каталоги должны быть расположены в /etc:
|
"/etc" opt |
"Конфигурационная информация для данного хоста" Конфигурация для /opt |
Дерево 3.7.2.1
Следующие каталоги либо символические ссылки на них должны быть расположены в /etc, если соответствующие пакеты установлены в системе:
|
"/etc" X11 sgml |
"Конфигурационная информация для данного хоста" Конфигурация системы X Window (optional) Конфигурация для SGML и XML (optional) |
Дерево 3.7.3.2
Следующие файлы либо символические ссылки на них должны быть расположены в /etc, если соответствующие пакеты установлены в системе: [примечание 5]
| csh.login | Общесистемный инициализационный файл для оболочки C-shell (optional) |
| exports | Список контроля доступа для сетевой файловой системы NFS (optional) |
| fstab | Постоянная информация для монтирования файловых систем (optional) |
| ftpusers | Список контроля доступа для демона FTP (optional) |
| gateways | Файл, содержащий список шлюзов для демона routed (optional) |
| gettydefs | Установки терминала, используемые демоном getty (optional) |
| group | Файл, определяющий списки групп пользователей в системе (optional) |
| host.conf | Файл конфигурации для системы разрешения имен (optional) |
| hosts | Постоянная информация об именах хостов (optional) |
| hosts.allow | Список хостов, с которых разрешен доступ в систему (optional) |
| hosts.deny | Список хостов, с которых запрещен доступ в систему (optional) |
| hosts.equiv | Список доверенных хостов для rlogin, rsh, rcp (optional) |
| hosts.lpd | Список доверенных (разрешенных) имен хостов для демона печати lpd (optional) |
| inetd.conf | Конфигурационный файл для демона inetd (optional) |
| inittab | Конфигурационный файл для init (optional) |
| issue | Сообщение, выдаваемое системой до регистрации пользователя (optional) |
| ld.so.conf | Список дополнительных каталогов для поиска разделяемых библиотек (optional) |
| motd | Сообщение, выдаваемое системой после регистрации пользователя (optional) |
| mtab | Динамически изменяющаяся информация о смонтированных файловых системах (optional) |
| mtools.conf | Конфигурационный файл для mtools (optional) |
| networks | Статическая информация о сетевых именах (optional) |
| passwd | Файл паролей (optional) |
| printcap | База данных с настройками принтеров для lpd (optional) |
| profile | Общесистемный файл инициализации для оболочки, запускаемой при входе пользователя в систему (optional) |
| protocols | Перечень IP-протоколов (optional) |
| resolv.conf | Конфигурационный файл для системы разрешения имен (optional) |
| rpc | Перечень протоколов удаленного вызова процедур (RPC) (optional) |
| securetty | Файл со списком устройств, с которых может заходить пользователь root (optional) |
| services | Имена портов для сетевых сервисов (optional) |
| shells | Список путей доступа для имеющихся в системе оболочек (optional) |
| syslog.conf | Конфигурационный файл для демона syslogd (optional) |
Таблица 3.7.3.1
Файл mtab не соответствует неизменяемой природе файлов, размещенных в /etc: он помещен в данный каталог в виде исключения по историческим причинам.[примечание 6]
Если конфигурационный файл должен располагаться в ином месте для того, чтобы пакет или система функционировали должным образом, этот файл может помещаться в каталог, отличный от /etc/opt/<package>.
| Xconfig | Конфигурационный файл для ранних версий XFree86 (optional) |
| XF86Config | Конфигурационный файл для XFree86 версий 3 и 4 (optional) |
| Xmodmap | Глобальный файл модификации клавиатуры в X11 (optional) |
Таблица 3.7.5.2.2
Среди подкаталогов в /etc/X11 могут находиться отдельные подкаталоги с конфигурационной информацией для xdm и других программ (например, для оконнных менеджеров), которые в такой информации нуждаются. [примечание 7]
[4] Размещение командных скриптов запуска может осуществляться в соответствии с моделями, принятыми в System V, BSD, или какими-то другими моделями. Более точные спецификации в этой области могут быть установлены будущими версиями настоящего стандарта.
[5] Системы, в которых используются теневые пароли, создают дополнительные конфигурационные каталоги и файлы в /etc (/etc/shadow и другие), а также размещают программы в каталоге /usr/sbin (useradd, usermod и другие).
[6] В некоторых Linux-системах это может быть символическая ссылка на /proc/mounts; в этом случае исключение не требуется.
[7] /etc/X11/xdm содержит конфигурационные файлы для xdm. В большинстве случаев это файлы, которые раньше размещались в /usr/lib/X11/xdm. Неоторые локальные переменные данные для xdm хранятся в /var/lib/xdm. Мы рекомендуем, чтобы оконные менеджеры с одним единственным конфигурационным файлом, который обычно по умолчанию имеет имя .*wmrc, переименовали его в system.*wmrc (если только нет общепринятого альтернативного названия) и не использовать подкаталог. Любой подкаталог для оконного менеджера должен называться так же, как называется исполняемый файл оконного менеджера.
[8] Разные люди предпочитают размещать
пользовательские каталоги в разных местах. Данная секция описывает только
предлагаемые варианты размещения домашних каталогов пользователей;
тем не менее мы рекомендуем, чтобы все FHS-совместимые дистрибутивы
использовали именно каталог /home как место размещения домашних каталогов.
В маленьких системах каждый пользовательский каталог является одним
из многих подкаталогов каталога /home, таких как /home/smith,
/home/torvalds, /home/operator и так далее.
В больших системах (особенно когда каталоги /home являются
разделяемыми между многими хостами посредством NFS) полезно
объединить домашние каталоги в группы, введя подкаталоги групп такие как
/home/staff, /home/guests,
/home/students и так далее. Но как бы то ни было структура домашних
каталогов различается от хоста к хосту. Следовательно,
никакая программа не должна полагаться на какие-то предположения
о структуре домашних каталогов.[примечание 9]
[9] Если вы хотите разыскать домашний каталог пользователя, вы должны использовать библиотечную функцию getpwent(3), а не полагаться на запись в /etc/passwd, потому что информация о пользователях может храниться на удаленных хостах, используя такие системы, как NIS.
| libc.so.* | Динамически подсоединяемые библиотеки C (optional) |
| ld* | Компоновщик/загрузчик времени выполнения (The execution time linker/loader) (optional) |
Таблица 3.9.2.1
Если препроцессор языка Си установлен, /lib/cpp должен быть ссылкой на него, по историческим причинам.[примечание 11]
|
"/lib" modules |
"Основные разделяемые библиотеки и модули ядра" Загружаемые модули ядра (optional) |
Дерево 3.9.3.1
[10] Разделяемые библиотеки, которые необходимы только исполняемым файлам, расположенным в /usr (таким как бинарные файлы системы X Window) НЕ должны располагаться в /lib. Только те разделяемые библиотеки, которые необходимы для запуска программ из /bin и /sbin могут располагаться здесь. В частности, библиотека libm.so.* может быть расположена в /usr/lib, если она не требуется никаким программам из /bin или /sbin.
[11] Обычное местоположение этого бинарного файла - /usr/lib/gcc-lib/<target>/<version>/cpp. /lib/cpp может быть либо прямой ссылкой на этот файл, либо ссылкой на любой другой указатель этого файла, существующий в файловой системе. (Например, часто используется /usr/bin/cpp).
Большие программные пакеты не должны использовать непосредственно подкаталоги каталога /usr в этой иерархии. (Large software packages must not use a direct subdirectory under the /usr hierarchy.)
[24] Локально устанавливаемые программы для системного алминистрирования должны размещаться в /usr/local/sbin.
Эта каталоговая структура предназначена для того, чтобы хранить файлы, используемые всеми архитектурными платформами данной ОС. Так, например, компьютеры на платформах i386, Alpha и PPC могут поддерживать один общий каталог /usr/share, который монтируется на отдельных компьютерах. Заметим, однако, что /usr/share обычно не предназначен для того, чтобы быть разделяемым различными операционными системами или различными версиями одной и той же ОС (or by different releases of the same OS).
Любая программа или пакет, который содержит или требует данных, не подлежащих модификации, должны хранить эти данные в каталоге /usr/share (или /usr/local/share, если пакет установлен локально). Рекомендуется использовать для этих целей подкаталоги каталога /usr/share.
Данные игровых программ, сохраняемые в /usr/share/games, должны быть чисто статическими данными. Любые модифицируемые файлы, такие как файлы результатов игр (score files), протоколы игр и так далее, должны размещаться в каталоге /var/games.
|
"/usr/share" man misc |
"Архитектурно-независимые данные" Онлайновые руководства Различные архитектурно-независимые данные |
Дерево 4.11.2.1
|
"/usr/share" dict doc games info locale nls sgml terminfo tmac zoneinfo |
"Архитектурно-независимые данные" Словари (optional) Различная документация (optional) Файлы статических данных для /usr/games (optional) Основная директория для системы GNU Info (optional) Локальная информация (optional) Каталоги сообщений для поддержки языков (Native language support) (optional) Данные для SGML и XML (optional) Каталог базы данных для terminfo (optional) Макросы для troff, не распространяемые с groff (optional) Конфигурационные файлы и информация о временной зоне (optional) |
Дерево 4.11.3.2
Рекомендуется размещать здесь создаваемые приложениями, архитектурно-независимые каталоги. К такого рода каталогам относятся groff, perl, ghostscript, texmf и kbd (Linux) или syscons (BSD). Они могут, однако, из соображений обратной совместимости, располагаться в /usr/lib, at the distributor's discretion. Подобным же образом в дополнение к каталогу /usr/share/games может создаваться каталог /usr/lib/games если разработчик желает разместить тут какие-то данные для своей игры.
| words | Список слов английского языка (optional) |
Таблица 4.11.4.2.1
В системах, где необходим как американский, так и британский английский, можно сделать words ссылкой на /usr/share/dict/american-english или /usr/share/dict/british-english.
Списки слов для других языков могут быть добавлены, используя английское название соответствующего языка, например, /usr/share/dict/french, /usr/share/dict/danish, и так далее. В названиях должен, по возможности, использоваться набор символов ISO 8859, соответствующий данному языку; если возможно, надо использовать набор символов Latin1 (ISO 8859-1) (зачастую это невозможно).
Другие списки слов тоже могут включаться в этот каталог, если они присутствуют.
Исходной директорией (<mandir>) для интерактивного руководства man в системе является каталог /usr/share/man. Этот каталог содержит информацию о командах и других данных, размещаемых в файловых системах / и /usr.[примечание 26]
Страницы интерактивного руководства хранятся в каталогах <mandir>/<locale>/man<section>/<arch>. Разъяснения того, что имеется в виду под <mandir>, <locale>, <section> и <arch> даются ниже.
Страница интерактивного руководства man разбиты на следующие секции:
|
"<mandir>/<locale>" man1 man2 man3 man4 man5 man6 man7 man8 |
"Иерархия страниц интерактивного руководства" Пользовательские программы (optional) Системные вызовы (optional) Библиотечные вызовы (optional) Специальные файлы (optional) Форматы файлов (optional) Игры (optional) Разное (optional) Системное администрирование (optional) |
Дерево 4.11.5.2.3
Компонент <section> задает секцию руководства.
Некоторые дополнения должны быть сделаны в структуре каталога /usr/share/man для поддержки страниц руководства, написанных на разных (или нескольких) языках. При внесении этих изменений необходимо иметь в виду место расположения и ссылки на эти страницы. Кроме того, приходится учитывать такие особенности языка как различия, обусловленные географическими факторами и различными кодировками.
Способ именования специфичных для языка подкаталогов /usr/share/man основан на Приложении E стандарта POSIX 1003.1, которое задает формат строки, идентифицирующей локаль, -- это общепринятый метод определения особенностей, определяемых культурой той или иной страны. Строка <locale> имеет следующий формат:
<language>[_<territory>][.<character-set>][,<version>]
Поле <language> должно браться из стандарта ISO 639 (коды для представления названий языков). Оно должно состоять из двух символов и записываться только в нижнем регистре.
Поле <territory> представляет собой, если это возможно, двух-буквенный код из ISO 3166 (спецификация представления названий стран). (a specification of representations of countries). (Большинство людей знакомы с двухбуквенными кодами, используемыми для обозначения стран в почтовых адресах. [примечание 29]). Это поле должно состоять из двух символов, записываемых только в верхнем регистре (заглавными буквами),
Поле <character-set> представляет собой стандартное описание кодировки (the character set). Если поле <character-set> представлено только цифрами, эти цифры представляют номер международного стандарта, описывающего набор символов (the number represents the number of the international standard describing the character set). Рекомендуется, если это возможно, чтобы это было числовое представление (в особенности стандартов ISO), не включающее дополнительных символов пунктуации, и чтобы любые символы были в нижнем регистре.
После поля <character-set> может располагаться параметр <version>, который отделяется запятой. Этот параметр может использоваться для выделения каких-то культурных различий; например, dictionary order versus a more systems-oriented collating order. Настоящий стандарт рекомендует не использовать поле <version>, если только это не является необходимым.
Системы, которые используют только один язык и набор символов для все страниц интерактивного руководства, могут опустить подстроку <locale> и хранить все страницы руководства в <mandir>. Например, системы, в которых страницы руководства имеются только на английском языке, причем в кодировке ASCII, могут хранить все страницы документации (каталоги man<section>) прямо в /usr/share/man. (Фактически это традиционное их местоположение.)
Страны, для которых есть общепринятый стандарт кодвого набора символов, могут опустить поле <character-set>, но мы настоятельно рекомендуем включить его, особенно для стран с несколькими конкурирующими стандартами.
Различные примеры:
| Язык | Территория | Набор символов (Character Set) | Каталог |
| Английский | -- | ASCII | /usr/share/man/en |
| Английский | Великобритания | ASCII | /usr/share/man/en_GB |
| Английский | Соединенные Штаты | ASCII | /usr/share/man/en_US |
| Французский | Канада | ISO 8859-1 | /usr/share/man/fr_CA |
| Французский | Франция | ISO 8859-1 | /usr/share/man/fr_FR |
| Немецкий | Германия | ISO 646 | /usr/share/man/de_DE.646 |
| Немецкий | Германия | ISO 6937 | /usr/share/man/de_DE.6937 |
| Немецкий | Германия | ISO 8859-1 | /usr/share/man/de_DE.88591 |
| Немецкий | Швейцария | ISO 646 | /usr/share/man/de_CH.646 |
| Японский | Япония | JIS | /usr/share/man/ja_JP.jis |
| Японский | Япония | SJIS | /usr/share/man/ja_JP.sjis |
| Японский | Япония | UJIS (or EUC-J) | /usr/share/man/ja_JP.ujis |
Таблица 4.11.5.2.2
Аналогичным образом некоторые изменения должны быть сделаны для страниц руковоства, которые зависят от архитектуры, таких как описания драйверов устройств или низкоуровневых команд системного администрирования. Таковые должны быть размещены в подкаталогах <arch> в соответсвующем каталоге man<section>; например, man-страница для команды ctrlaltdel(8) для архитектуры i386 может быть расположен в /usr/share/man/<locale>/man8/i386/ctrlaltdel.8.
Страницы руководства для команд и данных, размещаемых в /usr/local, хранятся в /usr/local/man. Страницы руководства для X11R6 хранятся в /usr/X11R6/man. Отсюда следует, что иерархия страниц руководства в системе должна иметь ту же самую структуру, что и /usr/share/man.
Секции руководства, отформатированные для вывода командой cat (cat<section>), тоже могут располагаться в подкаталогах каталога <mandir>/<locale>, но это не обязательно и оне не могут заменять страницы руководства в формате nroff.
Нумерация секций от "1" до "8" определена традициями. В общем случае имена файлов для страниц руководства, расположенных в определнной секции, оканчиваются расширением вида .<section>.
Кроме того, некоторые большие массивы страниц руководства, относящихся к определенным приложениям, могут иметь дополнительный суффикс, добавляемый к имени файла со страницей руководства. Например, для системы обработки почты MH файлы руководства должны иметь лополнительный суффикс mh в имени файла. Все страницы руководства для системы X Window System должны иметь дополнение x к имени файла.
Обычай размещения страниц интерактивного руководства для различных языков в соответствующих подкаталогах каталога /usr/share/man распространяется также на другие структуры каталогов с руководствами, такие как /usr/local/man и /usr/X11R6/man. (Эта часть стандарта применяется также к каталоговой структуре /var/cache/man, рассматриваемой ниже.)
Этот каталог содержит различные архитектурно-независимые файлы, для которых не требуется отдельный подкаталог в /usr/share.
| ascii | таблица набора символов ASCII (ASCII character set table) (optional) |
| magic | Список магических чисел (list of magic numbers) для команды file, используемый по умолчанию (optional) |
| termcap | База данных с параметрами терминалов (optional) |
| termcap.db | База данных с параметрами терминалов (optional) |
Таблица 4.11.6.1.3
Другие (специфические для отдельных приложений) файлы тоже могут размещаться здесь [примечание 30], но разработчики могут при желании разместить их также в /usr/lib.
|
"/usr/share/sgml" docbook tei html mathml |
"данные для SGML и XML" docbook DTD (optional) tei DTD (optional) html DTD (optional) mathml DTD (optional) |
Дерево 4.11.7.2.4
Другие файлы, которые не относятся к данному DTD, могут располагаться в их собственных подкаталогах.
[25] Многие их этих данных когда-то размещались в /usr (man, doc) или /usr/lib (dict, terminfo, zoneinfo).
[26] Очевидно, что файлы интерактивного руководства не нужны в корневой файловой системе /, потому что они не требуются во время загрузки системы и не являются необходимыми в чрезвычайных обстоятельствах. [примечание 27]
[27] Действительно.
[28] Например, если /usr/local/man не содержит файлов руководства в секции 4 (Устройства), то /usr/local/man/man4 может не создаваться.
[29] Главным исключением из этого правила является Великобритания (the United Kingdom), которая в ISO 3166 обозначается ка `GB', а в большинстве почтовых адресов как `UK'.
[30] Вот некоторые из таких файлов:
|
"/usr" bin include lib local sbin share |
"Каталоговоая структура второго уровня" Большая часть пользовательских команд Файлы заголовков (header files), включаемые в программы на языке C Библиотеки Каталоговая структура Local (пустая непосредственно после инсталляции системы) Системные утилиты, не являющиеся жизненно-важными (Non-vital system binaries) Архитектурно-независимые данные |
Дерево 4.2.1
|
"/usr" X11R6 games lib<qual> src |
"Каталоговая структура второго уровня" X Window System, version 11 release 6 (optional) Игры и обучающие программы (optional) Библиотеки для альтернативных форматов (optional) Исходные коды (optional) |
Дерево 4.3.1
Исключение сделано для системы X Window в силу сложившихся традиций и широко распространенной практики.
Могут создаваться следующие символические ссылки на каталоги.
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
/usr/spool/locks -> /var/lock
Эта возможность обусловлена необходимостью сохранить совместимость со старыми системами до тех пор, пока все реализации не начнут использовать каталоги, размещенные непосредственно в /var.
Если система уже не требует наличия указанных ссылок, они могут быть удалены, если есть такое желание.
Для некоторого упрощения и сохранения совместимости XFree86 с системой X Window для других типов операционных систем должны быть созданы следующие символические ссылки, если только каталог /usr/X11R6 существует:
/usr/bin/X11 -> /usr/X11R6/bin
/usr/lib/X11 -> /usr/X11R6/lib/X11
/usr/include/X11 -> /usr/X11R6/include/X11
В общем случае программное обеспечение не должно использовать перечисленные символические ссылки при инсталляции или в целях управления. Они предназначены только для пользователей. Трудности связаны с версиями выпусков системы X Window -- в переходный период невозможно узнать, какая версия X11 используется.
[17] Примерами таких конфигурационных файлов могут служить Xconfig, XF86Config или system.twmrc.
|
"/usr/bin" mh |
"Исполняемые файлы, которые не нужны в однопользовательском режиме" Команды для системы обработки почты MH (MH mail handling system) (optional) |
Дерево 4.5.2.1
/usr/bin/X11 должен быть символической ссылкой на /usr/X11R6/bin если последний существует.
Следующие файлы или символические ссылки на файлы должны быть размещены в /usr/bin, если только соответствующие пакеты установлены в системе:
| perl | Язык Perl (The Practical Extraction and Report Language) (optional) |
| python | Интерпретирующий язык Python (optional) |
| tclsh | Оболочка интерпретатора Tcl (optional) |
| wish | Оболочка Tcl/Tk (optional) |
| expect | Программа для организации интерактивного диалога (optional) |
Таблица 4.5.2.1
|
"/usr/include" bsd |
"Подключаемые файлы" BSD-совместимые подключаемые файлы (optional) |
Дерево 4.6.2.1
Символическая ссылка /usr/include/X11 должны указывать на /usr/X11R6/include/X11, если тлько последний существует.
Приложения могут использовать отдельные подкаталоги в /usr/lib. Если приложение использует подкаталог, все архитектурно-зависимые данные, используемые только этим приложением, должны размещаться внутри этого подкаталога. [примечание 19]
По историческим причинам /usr/lib/sendmail должен быть символической ссылкой на /usr/sbin/sendmail, если последний существует. [примечание 20]
Если /lib/X11 существует, /usr/lib/X11 должен быть символической ссылкой на /lib/X11, либо на тот каталог, на который ссылается /lib/X11.[примечание 21]
[18] Различные архитектурно-зависимые статические файлы и подкаталоги, специфичные для отдельных приложений, должны размещаться в /usr/share.
[19] Например, подкаталог perl5 для модулей и библиотек Perl 5.
[20] Некоторые исполняемые команды, такие как makewhatis и sendmail тоже по традиции размещаются в /usr/lib. makewhatis - это внутреннй исполняемый файл и должен размещаться в подкаталоге для бинарных файлов; пользователям предоставляется доступ только к catman. Исполняемые файлы последних версий sendmail теперь по умолчанию располагаются в /usr/sbin. Кроме того, системы, использующие sendmail-совместимые агенты передачи почты, должны делать /usr/sbin/sendmail символической ссылкой к соответствующему исполняемому файлу.
[21] Специфичные для каждого хоста данные для системы X Window не должны размещаться в /usr/lib/X11. Специфичные для хоста конфигурационные файлы, такие как Xconfig или XF86Config должны храниться в /etc/X11. Это требование относится и к таким фонфигурационным данным, как system.twmrc, даже если это только символическая ссылка на более общий конфигурационный файл (вероятно в /usr/X11R6/lib/X11).
[22] В случае, когда /usr/lib и /usr/lib<qual> есть фактически одно и то же (один из них есть просто символическая ссылка на другой) эти файлы и подкаталоги для отдельных приложений будут существовать.
Локально устанавливаемое программное обеспечение должно располагаться не в /usr, а в /usr/local если только его установка производится не в целях замены или обновления ПО в /usr. [примечание 23]
|
"/usr/local" bin games include lib man sbin share src |
"Каталог для локального ПО" Локальные исполняемые файлы Локально установленные игровые приложения Локальные заголовочные файлы для C Локальные библиотеки Локальные онлайновые руководства Локальные системные исполняемые файлы Архитектурно-независимые каталоговая структура для локального ПО Локально установленные исходные коды |
Дерево 4.9.2.1
Никаких каталогов, кроме перечисленных выше, не должно быть в /usr/local после первой установки FHS-совместимой системы.
[23] Программное обеспечение, расположенное в / или /usr может быть перезаписано при обновлениях системы (хотя мы рекомендуем, чтобы дистрибутивы не перезаписывали данные в /etc в таких обстоятельствах). По этой причине локально устанавливаемое программное обеспечение не должно размещаться за пределами каталога /usr/local без достаточных на то оснований.
Каталог /var содержит файлы с изменяющимися данными. В их число входят каталоги и файлы спулинга, данные об администрировании и логировании, временные файлы.
Некоторые части каталоговой структуры /var не являются разделяемыми между разными системами. К ним относятся /var/log, /var/lock и /var/run. Другие части могут быть разделяемыми, например, /var/mail, /var/cache/man, /var/cache/fonts и /var/spool/news.
Каталоговая структура /var определяется здесь с той целью, чтобы сделать возможным монтирование каталога /usr в режиме только для чтения. Все, что записывается на диск в процессе выполнения системных операций (в противоположность процессам инсталляции и поддержки программного обеспечения), должно размещаться в каталоге /var.
Если /var не может быть размещен в отдельном разделе диска, зачастую предпочительнее переместить каталог /var из корневого раздела в раздел с каталогом /usr. (Иногда это делается с целью уменьшения размера корневого раздела или когда в корневом разделе остается слишком мало места). Однако, /var нельзя делать ссылкой на /usr потому что это затрудняет разделение /usr и /var и может привести к конфликту имен. Лучше уж сделать /var ссылкой на /usr/var.
Приложения в общем случае не должны добавлять каталоги непосредственно в /var. Такие каталоги могут создаваться только в силу каких-то общесистемных соображений и после консультаций через лист рассылки FHS.
| lastlog | запись о последнем входе в систему каждого пользователя |
| messages | системные сообщения от syslogd |
| wtmp | записи о всех входах и выходах пользователей в систему |
Table 5.10.2.1
Файлы почтовых ящиков в этих каталогах должны хранится в формате стандартных почтовых ящиков UNIX (UNIX mailbox format).
Важно заметить, что нет требования физически переместить область спулинга в указанный каталог. Однако программы и заголовочные файлы должны быть изменеы так, чтобы они использовали /var/mail.
[36] Заметьте, что /var/mail может быть символической ссылкой на другой каталог.
Внутренний формат для файлов, в которых хранятся идентификаторы процесов (PID), остаются неизменными. Файл должен состоять из идентификатора процесса в коде ASCII, записанном в десятичной нотации, за которым следует символ конца строки. Например, если crond запущен как процесс с номером 25, /var/run/crond.pid будет содержать три символа: два, пять и символ новой строки.
Программы, которые читают PID-файлы, должны быть достаточно гибкими в отношении того, что они воспринимают: то есть они должны игнорировать лишние пробелы, предшествующие ноли, отсутствие завершающего символа новой строки или дополнительные строки в PID-файле. Программы, которые создают PID-файлы, должны использовать простые спецификации, изложенные в предыдущем параграфе.
Файл utmp, в котором хранится информация о том, кто в данный момент использует систему, расположен в этом каталоге.
Программы, которые поддерживают transient UNIX-domain sockets, должны размещать их в этом каталоге.
[37] Непривелигированные пользователи должны быть лишены права записи в каталог /var/run; с точки зрения безопасности предоставление любому пользователю права записи в этот каталог представляет большую угрозу. Файлы с идентификаторами процессов (PID), которые раньше располагались в /etc, должны быть размещены в /var/run. Соглашение об именах этих файлов следующее: <program-name>.pid. Например, PID-файл для демона crond называется /var/run/crond.pid.
|
"/var/spool" lpd mqueue news rwho uucp |
"Каталоги очередей (спулинга)" Каталог спулинга для принтера (optional) Очередь исходящей почты (optional) Каталог спулинга новостей (optional) Файлы программы Rwhod (optional) Каталог спулинга для UUCP (optional) |
Дерево 5.14.2.1
Файл блокировки для lpd, lpd.lock, должен размещаться в /var/spool/lpd. Предполагается, что файл блокировки для каждого принтера размещается в каталоге спулинга для этого конкретного принтера и называется lock.
|
"/var/spool/lpd" <printer> |
"Каталог спулинга для принтера" Очереди печати для конкретного принтера (optional) |
Дерево 5.14.3.2.2
[38] Файлы блокировки для UUCP должны размещаться в каталоге /var/lock. Смотри выше секцию о /var/lock.
Файлы и каталоги, размещенные в /var/tmp, не должны удаляться, когда система (пере)загружается. Хотя данные, сохраняемые в /var/tmp, обычно удаляются специфичным для каждого сайта образом, рекомендуется удалять их чаще, чем данные в /tmp.
[39] Не путайте NIS с Sun NIS+, которая использует другой каталог, /var/nis.
|
"/var" cache lib local lock log opt run spool tmp |
"Переменные данные" Данные из кэшей приложений Переменная информация о состоянии приложений Переменные данные для /usr/local Файлы блокирования устройств и программ Каталоги и файлы протоколов Переменные данные для /opt Данные, относящиеся к запущенным процессам Данные очередей, создаваемых приложениями Временные файлы, сохраняемые между перезапусками системы |
Дерево 5.2.1
Несколько каталогов "зарезервированы" в том смысле, что они не должны использоваться произвольным образом каким-либо из новых приложений, поскольку это противоречить исторической или локальной практике их использования. Это следующие каталоги:
/var/backups
/var/cron
/var/msgs
/var/preserve
|
"/var" account crash games yp |
"Переменные данные" Протоколы работы процессов (optional) Дампы памяти при крахе системы (optional) Временные данные игровых приложений (optional) User mailbox files (optional) Файлы базы данных Network Information Service (NIS) (optional) |
Tree 5.3.1
Файлы, расположенные в /var/cache, могут удаляться либо самим приложением, либо администратором. Приложение должно всегда иметь возможность продолжить работу после удаления этих файлов вручную (например, при нехватке дискового пространства). Никаких других требований на формат данных к каталоге кэша не накладывается.
|
"/var/cache" fonts man www <package> |
"Каталоги кэширования" Локально сгенерированные шрифты (optional) Локально отформатированные страницы руководства (optional) Кэш данных для WWW proxy (optional) Кэшируемые данные пакета <package> (optional) |
Дерево 5.5.2.1
Каталог /var/cache/fonts должен использоваться для хранения динамически создаваемых шрифтов. В частности, все шрифты, автоматически генерируемые программой mktexpk, должны размещаться в соответствующим образом названных подкаталогах каталога /var/cache/fonts. [примечание 31]
Структура каталога /var/cache/man должна соответствовать наличию нескольких отдельных деревьев каталогов для страниц руководства и возможности наличия многоязыковой поддержки.
В предположении, что неформатированные страницы руководства расположены в каталогах <path>/man/<locale>/man<section>, форматированные страницы должны располагаться в каталоге /var/cache/man/<catpath>/<locale>/cat<section>, где <catpath> получается из <path> путем удаления подстроки usr из начала и подстроки share в конце имени каталога. [примечание 32] (Обратите внимание на то, что компонент <locale> может отсутствовать.)
Страницы руководства, записанные в /var/cache/man, могут быть перенесены в исходные каталоги структуры man или удалены; подобным же образом отформатированные страницы руководства в каталоге man могут быть удалены, если они не использовались в течение какого-то периода времени.
Если заранее отформатированные страницы руководства поставляются с системой на носителе, допускающем только чтение (например, на CD-ROM), они должны устанавливаться в исходную каталоговую структуру man (то есть в /usr/share/man/cat<section>). Каталог /var/cache/man зарезервирован как перезаписываемый кэш для отформатированных страниц руководства.
[31] Настоящий стандарт пока не предусматривает поглощение или замену the TeX Directory Structure (документ, который задает размещение файлов формата TeX и структуру соответствующих каталогов), так что этот документ полезно прочитать. Он размещается по адресу ftp://ctan.tug.org/tex/.
[32] Например, отформатированный вариант страницы /usr/share/man/man1/ls.1 размещается как /var/cache/man/cat1/ls.1, а /usr/X11R6/man/<locale>/man3/XtClass.3x - как /var/cache/man/X11R6/<locale>/cat3/XtClass.3x.
Эта каталоговая структура содержит информацию о состоянии отдельных приложений или всей системы. Информация о состоянии - это данные, которые программы изменяют в процессе своей работы, относящиеся к одному конкретному хосту. У пользователей нет нужды менять эти файлы для настройки действий пакета.
Информация о состоянии в общем случае используется для сохранения состояния приложения (или группы взаимосвязанных приложений) между двумя запусками или передачи такой информации между двумя одновременно запущенными копиями одного и того же приложения. Информация о состоянии, в общем случае, должна сохраняться после перезагрузки системы, не должна совпадать с протоколируемым выводом программы и данными из очередей (spooled data).
Приложение (или группа взаимосвязанных приложений) должно использовать отдельный подкаталог в /var/lib для своих данных. [примечание 33] Имеется одна обязательная директория, /var/lib/misc, которая предназначена для файлов состояния, которые не требуют отдельного подкаталога; остальные подкаталоги должны присутствовать если соответствующее приложение включено в дистрибутив.
/var/lib/<name> - местоположение, которое должно использоваться для каждого пакета из дистрибутива. Разные дистрибутивы могут, естественно, разные имена.
|
"/var/lib" misc |
"Изменяемая информация о состоянии" Различные данные о состоянии |
Дерево 5.8.2.1
|
"/var/lib" <editor> <pkgtool> <package> hwclock xdm |
"Переменные данные о состоянии системы" Резервные копии редактируемых файлов и данные о состоянии редактора (optional) Файлы поддержки системы управления пакетами (optional) Данные о состоянии пакетов и подсистем (optional) Каталог с данными о состоянии hwclock (optional) Изменяемые данные для менеджера дисплея (optional) |
Дерево 5.8.3.2
Другие редакторы могут не требовать каталога для сохранения файлов на случай краха программы, но могут требовать четко определенного места для хранения другой информации в то время, когда редактор запущен. Такая информация может храниться в подкаталогах каталога /var/lib (например, GNU Emacs размещает файлы блокирования в /var/lib/emacs/lock).
Другие редакторы могут требовать хранения дополнительной информации о состоянии кроме резервных копий файлов и файлов блокирования - такая информация тоже должна размещаться в /var/lib/<editor>.
Специфичные для каждого редактора файлы блокирования обычно сильно отличаются от файлов блокирования устройств или ресурсов, которые хранятся в /var/lock и поэтому хранятся в /var/lib.
[33] Важное различие между настоящей версией этого стандарта и предыдущими состоит в том, что от приложений не требуется использовать подкаталоги каталога /var/lib.
[34] Эта каталоговая структура должна содержать файлы, которые в текущих версиях BSD хранятся в /var/db. В их число входят locate.database и mountdtab, а также базу(ы) символов ядра.
Файлы блокирования устройств и других ресурсов, используемые многими приложениями, такие как файлы блокирования последовательных портов, которые ранее находились либо в /usr/spool/locks, либо в /usr/spool/uucp, теперь должны размещаться в /var/lock. Названия этих файлов должны формироваться в соответствии с соглашением, согласно которому используется префикс "LCK..", за которым следует базовое имя устройства. Например, для блокирования /dev/ttyS0 должен создаваться файл "LCK..ttyS0". [примечание 35]
Внутренняя структура таких файлов блокирования должна соответствовать формату, определенному в HDB UUCP. Формат HDB предусматривает сохранение идентификатора процесса (PID) в виде десяти-байтового десятичного числа, за которым следует символ конца строки. Например, если процесс 1230 создает файл блокирования, в этом файле будет записано 11 символов: пробел, пробел, пробел, пробел, пробел, пробел, один, два, три, ноль и конец строки.
[35] Затем все, кто хочет использовать /dev/ttyS0 может прочитать файл блокирования и действовать соответственно (все файлы блокирования в /var/lock должны быть доступны по чтению всем).
Настоящее дополнение к стандарту относится только к операционной системе Linux.
В Linux-системах, если ядро расположено в /, мы рекомендуем использовать для него названия vmlinux или vmlinuz, которые используются в последних версиях исходных кодов ядра Linux.
Linux-системы, в которых следующие файлы требуются, должны помещать их в /bin.
Все устройства и специальные файлы в /dev должны соответствовать документу Linux Allocated Devices, который поставляется в составе исходных кодов ядра. Он поддерживается Питером Анвином (H. Peter Anvin) <адрес пропущен>.
Символические ссылки в каталоге /dev должны устанавливаться в Linux-системах не иначе как в соответствии с документом Linux Allocated Devices.
Если в Linux-системе следующие файлы требуются, они должны размещаться в /etc.
Файловая система proc является фактически стандартным для Linux методом обработки информации о системе и процессах, в отличие от других систем, использующих /dev/kmem и другие подобные методы. Мы настоятельно рекомендуем использовать proc для хранения и получения информации о процессах, а также информации о ядре и памяти.
В Linux-системах следующие дополнительные файлы размещаются в /sbin.
Статические исполняемые файлы ln (sln) и sync (ssync) используются в тех случаях, когда нормальный ход вещей нарушается. Основное назначение sln (восстанавливать некорректные символические ссылки в /lib после плохо организованного обновления) потеряло теперь былую важность, потому что имеется программа ldconfig (обычно расположенная в /usr/sbin), которая используется для обновления динамических библиотек. Программа sync полезна в некоторых критических ситуациях. Заметим, что эти файлы не обязаны, но могут быть ссылками на стандартные программы ln и sync.
Программа ldconfig не обязана размещаться в /sbin, поскольку сайт может использовать запуск ldconfig на этапе начальной загрузки, а не только во время обновления разделяемых библиотек. (Не ясно, имеются ли какие-то преимущества в запуске ldconfig при каждой загрузке системы.) Но даже если это так, некоторые люди любят использовать ldconfig в следующих (часто встречающихся) ситуациях:
Чтобы найти выход из ситуации, когда некоторые клавиатуры поставляются с такой высокой скоростю повторения, что оказываются непригодны к использованию, kbdrate может быть в некоторых системах установлена в /sbin.
Поскольку действием, которое ядро по умолчанию связывает с нажатием комбинации клавиш Ctrl-Alt-Del, является немедленная перезагрузка, обычно рекомендуется отменить отменить такое поведение перед монтированием корневой файловой системы в режиме только для чтения. Некоторые варианты демона init способны отменить действие Ctrl-Alt-Del, а другие требуют наличия программы ctrlaltdel, которая может быть установлена в таких системах в каталоге /sbin.
Эти символические ссылки требуются, если компиляторы языков C или C++ установлены и только для систем, не основанных на glibc.
/usr/include/asm -> /usr/src/linux/include/asm-<arch>
/usr/include/linux -> /usr/src/linux/include/linux
Для систем, основанных на glibc, нет никаких специфических правил для этого каталога. Для систем, основанных на версиях библиотеки libc, предшествующих glibc, применяются следующие правила:
Единственными исходными кодами, которые должны быть размещены в определенном месте, являются исходные коды ядра Linux. Они размещаются в /usr/src/linux.
Если установлен компилятор C или C++, а полная версия исходных кодов ядра не установлена, то подключаемые файлы из исходных кодов ядра должны размещаться в следующих каталогах:
/usr/src/linux/include/asm-<arch>
/usr/src/linux/include/linux
где <arch> - название архитектуры системы (например, i386).
Замечание: /usr/src/linux может быть символической ссылкой на дерево каталогов с исходными кодами ядра.
Этот каталог содержит переменные данные для программ-демонов cron и at.
Этот раздел содержит дополнительные требования и рекомендации, которые применимы только для отдельных операционных систем. Материал в этом разделе не должен противоречить основному стандарту.
Список рассылки FHS располагается по адресу <адрес пропущен>. Для того, чтобы подписаться на рассылку, пошлите сообщение по адресу <адрес пропущен>, текст которого имеет вид "ADD fhs-discuss".
Спасибо Network Operations at the University of California в Сан-Диего, позволившим нам использовать их великолепный сервер почтовых рассылок.
Как было отмечено во введении, пожалуйста не посылайте писем в список рассылки, не проведя предварительных переговоров с редактором FHS или одним из перечисленных ниже разработчиков.
Процесс создания стандарта на структуру каталогов файловой системы начался в августе 1993 года с попытки упорядочить структуру файлов и каталогов операционной системы Linux. Стандарт FSSTND, ориентированный только на систему Linux, был выпущен 14 февраля 1994 года. Последующие редакции были выпущены 9 октября 1994 и 28 марта 1995 года.
В начале 1995 года с участием сообщества разработчиков системы BSD была поставлена цель создания более общей версии FSSTND, предназначенной не только для Linux, но и для других UNIX-подобных операционных систем. В результате объединенных усилий разработка стандарта сосредоточилась на вопросах, которые являются общими для всех UNIX-подобных систем. В качестве признания расширения сферы охвата действия стандарта его название было изменено на Filesystem Hierarchy Standard или, для краткости, FHS.
Добровольцы, которые активно участвовали в создании стандарта, перечислены в конце настоящего документа. Этот стандарт представляет собой общую точку зрения перечисленных и других участников разработки.
При разработке стандарта мы стремились достичь следующих целей:
Этот документ задает спецификацию стандартной структуры каталогов файловой системы (или иерархию файловой системы), определяя требования к размещению каталогов и файлов, а также содержание некоторых системных файлов.
Стандарт создавался для использования системными интеграторами, разработчиками пакетов программного обеспечения и системными администраторами в процессе создания и поддержки FHS-совместимых файловых систем. Он должен служить в первую очередь как справочник, а не как учебник по построению структуры каталогов (not a tutorial on how to manage a conforming filesystem hierarchy).
Стандарт FHS вырос из предыдущей разработки - стандарта FSSTND на организацию файловой системы в операционной системе Linux. Он является расширением FSSTND, ориентированным в первую очередь на вопросы межсистемного взаимодействия не только между Linux-системами, но в более широкой области, включающей операционные системы типа 4.4BSD. Он учитывает все положительные качества, присущие BSD и другим системам в части поддержки различных архитектур и учета требований работы в гетерогенных сетях.
Хотя этот стандарт и является более всеохватывающим по сравнению с предыдущим вариантом в части стандартизации файловой системы, могут потребоваться его периодические обновления по мере изменения требований со стороны вновь появляющихся технологий. Возможно также, что будут найдены лучшие решения рассатриваемых в стандарте проблем, так что наши решения перестанут быть наилучшими. Поэтому периодически могут появляться как новые редакции стандарта, так и отдельные предложения по его изменению, предназначенные для предварительного обсуждения. Однако одной из наших целей является сохранение обратной совместимости последовательных выпусков стандарта.
Приветствуются любые комментарии, касающиеся содержания стандарта. Любые комментарии или предложения по его изменению могут направляться редактору FHS (Daniel Quinlan <адрес пропущен>) или в список рассылки FHS. Сообщения о типографских или грамматических ошибках должны направляться редактору FHS.
Прежде чем отправить письмо в список рассылки, необходимо связаться с редактором FHS, чтобы не обсуждать старые темы.
Иногда могут возникать вопросы о том, как следует интерпретировать отдельные положения настоящего документа. Если вам требуются какие-то пояснения, обращайтесь к редактору FHS. Поскольку стандарт представляет собой результат соглашения, к которому пришли все участники разработки, необходимо убедиться, что любая интерпретация его положений тоже представляет коллективное мнение. По этой причине может оказаться невозможным немедленно ответить на ваш запрос, если только содержание вопроса не было темой предшествующих дискуссий.
Разработчики стандарта FHS хотели бы поблагодарить разработчиков, системных администраторов и пользователей, котоорые внесли свой вклад в разработку настоящего стандарта. Мы благодарны всем тем, кто помогал писать, составлять и отлаживать настоящий стандарт.
Группа разработки стандарта (The FHS Group) также благордарит тех разработчиков ОС Linux, которые поддержали FSSTND, предшественника настоящего стандарта. Если бы они не продемонстрировали, что FSSTND был полезен (was beneficial), стандарт FHS никогда бы не был создан.
| Brandon S. Allbery | <address omitted> |
| Keith Bostic | <address omitted> |
| Drew Eckhardt | <address omitted> |
| Rik Faith | <address omitted> |
| Stephen Harris | <address omitted> |
| Ian Jackson | <address omitted> |
| John A. Martin | <address omitted> |
| Ian McCloghrie | <address omitted> |
| Chris Metcalf | <address omitted> |
| Ian Murdock | <address omitted> |
| David C. Niemi | <address omitted> |
| Daniel Quinlan | <address omitted> |
| Eric S. Raymond | <address omitted> |
| Rusty Russell | <address omitted> |
| Mike Sangrey | <address omitted> |
| David H. Silber | <address omitted> |
| Thomas Sippel-Dau | <address omitted> |
| Theodore Ts'o | <address omitted> |
| Stephen Tweedie | <address omitted> |
| Fred N. van Kempen | <address omitted> |
| Bernd Warken | <address omitted> |
Таблица 7.6.1
Необходимость в отдельном предисловии переводчика обусловлена теми затруднениями, которые возникли у меня в процессе перевода некоторых терминов, и желанием пояснить выбор русского эквивалента, что, надеюсь, поможет читателю в правильном понимании и толковании текста стандарта.
И начать свои пояснения я хочу с рассуждения о выборе русского варианта названия стандарта. Дословный перевод названия ("Стандарт иерарахии файловой системы"), хотя он уже встречается в литературе (например, в книге Д.Бендела и Р.Нейпира "Использование Linux", М., "Вильямс", 2002 г.) кажется мне неудачным из-за того, что слово "иерархия" имеет в русском языке смысл, несколько отличающийся от смысла, вкладываемого в словосочетание "иерархическая структура". Возможно, в английском термин "Hierarchy" имеет много оттенков и точно выражает суть стандарта, а может быть он употреблен в названии только для краткости. Я не настолько хорошо владею английским, чтобы уверенно отстаивать какое-то из этих утверждений. Но для русского текста дословный перевод показался мне не адекватным содержанию, и я думаю, что для русскоязычного варианта имеет смысл подобрать сочетание терминов, более полно и точно выражающее его содержание.
В процессе перевода стандарта я долго размышлял над выбором такого сочетания, перебрал несколько формулировок и в конце концов решил, что наиболее правильным вариантом будет "Стандарт на структуру каталогов файловой системы" или "Стандартная структура каталогов файловой системы".
Теперь еще о нескольких терминах.
Описание большинства каталогов в стандарте начинается с двух разделов, которые имеют в оригинале названия "Requirements" и "Specific Options". Первый термин переводится однозначно как "Требования", а второй термин можно перевести по разному. В конце концов я выбрал вариант "Рекомендации", поскольку в этом разделе речь в большинстве случаев идет о тех подкаталогах рассматриваемого каталога, которые могут создаваться, а могут и не создаваться, в зависимости от того, устанавливаются ли соответствующие подсистемы. В общем-то речь всегда идет о требованиях создания определенных подкаталогов в текущем каталоге, но называть раздел "необязательные требования" как-то не по-русски. Так что пришлось назвать рекомендациями, хотя мне кажется, что это все-же требования, но по отношению к необязательным каталогам.
Во многих разделах стандарта присутствуют пояснения, которые заключены между строками "Begin Rationale" и "End Rationale". Термин "Rationale" в англо-русском словаре переводится как "обоснования", но мне кажется более приемлемым именно "Пояснения", которое я и использую.
И еще. Если я где-то не совсем верно перевел текст стандарта, это моя вина, не относите все ошибки на счет разработчиков стандарта. О любых замеченных вами ошибках прошу сообщать мне по адресу kos@linux-ve.net.
В.А.Костромин, 9 января 2003 года.