6 Дополнения, специфичные для отдельных типов операционных систем
Этот раздел содержит дополнительные требования и рекомендации, которые применимы только для отдельных операционных систем. Материал в этом разделе не должен противоречить основному стандарту.
6.1 Linux
Настоящее дополнение к стандарту относится только к операционной системе Linux.
6.1.1 / : Корневой каталог
В Linux-системах, если ядро расположено в /, мы рекомендуем использовать для него названия vmlinux или vmlinuz, которые используются в последних версиях исходных кодов ядра Linux.
6.1.2 /bin : Основные исполняемые файлы команд пользователя (доступные всем пользователям)
Linux-системы, в которых следующие файлы требуются, должны помещать их в /bin.
- { setserial }
6.1.3 /dev : Устройства и специальные файлы
Все устройства и специальные файлы в /dev должны соответствовать документу Linux Allocated Devices, который поставляется в составе исходных кодов ядра. Он поддерживается Питером Анвином (H. Peter Anvin) <адрес пропущен>.
Символические ссылки в каталоге /dev должны устанавливаться в Linux-системах не иначе как в соответствии с документом Linux Allocated Devices.
НАЧАЛО ПОЯСНЕНИЙ
Требование не создавать символических ссылок произвольным образом выдвигается потому, что локальные установки часто отличаются от ссылок, создаваемых программами установки от разработчиков. Кроме того, если установочный скрипт дистрибутива создает символические ссылки во время инсталляции, эти ссылки часто не обновляются при локальных изменениях в аппаратном обеспечении. Если же ответственно относиться к ним на локальном уровне, они могут использоваться.
КОНЕЦ ПОЯСНЕНИЙ
6.1.4 /etc : Специфичная для данного хоста конфигурационная информация
Если в Linux-системе следующие файлы требуются, они должны размещаться в /etc.
- { lilo.conf }
6.1.5 /proc : Виртуальные файловые системы для хранения информации о ядре и процессах
Файловая система proc является фактически стандартным для Linux методом обработки информации о системе и процессах, в отличие от других систем, использующих /dev/kmem и другие подобные методы. Мы настоятельно рекомендуем использовать proc для хранения и получения информации о процессах, а также информации о ядре и памяти.
6.1.6 /sbin : Основные системные утилиты
В Linux-системах следующие дополнительные файлы размещаются в /sbin.
- Команды для управления файловой системой ext2fs (Second extended filesystem) (optional):
- { badblocks, dumpe2fs, e2fsck, mke2fs, mklost+found, tune2fs }
- Программа установки загрузчика системы (optional):
- { lilo }
Дополнительные файлы в /sbin:
- Неизменяемые исполняемые файлы:
- { ldconfig, sln, ssync }
Статические исполняемые файлы ln (sln) и sync (ssync) используются в тех случаях, когда нормальный ход вещей нарушается. Основное назначение sln (восстанавливать некорректные символические ссылки в /lib после плохо организованного обновления) потеряло теперь былую важность, потому что имеется программа ldconfig (обычно расположенная в /usr/sbin), которая используется для обновления динамических библиотек. Программа sync полезна в некоторых критических ситуациях. Заметим, что эти файлы не обязаны, но могут быть ссылками на стандартные программы ln и sync.
Программа ldconfig не обязана размещаться в /sbin, поскольку сайт может использовать запуск ldconfig на этапе начальной загрузки, а не только во время обновления разделяемых библиотек. (Не ясно, имеются ли какие-то преимущества в запуске ldconfig при каждой загрузке системы.) Но даже если это так, некоторые люди любят использовать ldconfig в следующих (часто встречающихся) ситуациях:
- Я только что удалил /lib/
. - Я не могу узнать (разыскать) имя библиотеки, потому что ls связано динамически (is dynamically linked), я использую оболочку, которая не имеет встроенной команды ls, а я не знаю, что вместо нее можно использовать "echo *".
- У меня есть статическая ссылка sln, но я не знаю, что она вызывает.
- Разное:
- { ctrlaltdel, kbdrate }
Чтобы найти выход из ситуации, когда некоторые клавиатуры поставляются с такой высокой скоростью повторения, что оказываются непригодны к использованию, kbdrate может быть в некоторых системах установлена в /sbin.
Поскольку действием, которое ядро по умолчанию связывает с нажатием комбинации клавиш Ctrl-Alt-Del, является немедленная перезагрузка, обычно рекомендуется отменить отменить такое поведение перед монтированием корневой файловой системы в режиме только для чтения. Некоторые варианты демона init способны отменить действие Ctrl-Alt-Del, а другие требуют наличия программы ctrlaltdel, которая может быть установлена в таких системах в каталоге /sbin.
6.1.7 /usr/include : Файлы заголовков, включаемые в программы на C
Эти символические ссылки требуются, если компиляторы языков C или C++ установлены и только для систем, не основанных на glibc.
/usr/include/asm -> /usr/src/linux/include/asm-/usr/include/linux -> /usr/src/linux/include/linux
6.1.8 /usr/src : Исходные коды
Для систем, основанных на glibc, нет никаких специфических правил для этого каталога. Для систем, основанных на версиях библиотеки libc, предшествующих glibc, применяются следующие правила:
Единственными исходными кодами, которые должны быть размещены в определенном месте, являются исходные коды ядра Linux. Они размещаются в /usr/src/linux.
Если установлен компилятор C или C++, а полная версия исходных кодов ядра не установлена, то подключаемые файлы из исходных кодов ядра должны размещаться в следующих каталогах:
/usr/src/linux/include/asm-/usr/src/linux/include/linux
где
Замечание: /usr/src/linux может быть символической ссылкой на дерево каталогов с исходными кодами ядра.
НАЧАЛО ПОЯСНЕНИЙ
Важно, чтобы подключаемые файлы ядра были расположены в /usr/src/linux, а не в /usr/include, так чтобы не было проблем, когда системные администраторы обновляют версию ядра в первый раз.
КОНЕЦ ПОЯСНЕНИЙ
6.1.9 /var/spool/cron : Задания для демонов cron и at
Этот каталог содержит переменные данные для программ-демонов cron и at.
7.1 Список рассылки FHS
Список рассылки FHS располагается по адресу <адрес пропущен>. Для того, чтобы подписаться на рассылку, пошлите сообщение по адресу <адрес пропущен>, текст которого имеет вид "ADD fhs-discuss".
Спасибо Network Operations at the University of California в Сан-Диего, позволившим нам использовать их великолепный сервер почтовых рассылок.
Как было отмечено во введении, пожалуйста не посылайте писем в список рассылки, не проведя предварительных переговоров с редактором FHS или одним из перечисленных ниже разработчиков.
7.2 История стандарта FHS
Процесс создания стандарта на структуру каталогов файловой системы начался в августе 1993 года с попытки упорядочить структуру файлов и каталогов операционной системы Linux. Стандарт FSSTND, ориентированный только на систему Linux, был выпущен 14 февраля 1994 года. Последующие редакции были выпущены 9 октября 1994 и 28 марта 1995 года.
В начале 1995 года с участием сообщества разработчиков системы BSD была поставлена цель создания более общей версии FSSTND, предназначенной не только для Linux, но и для других UNIX-подобных операционных систем. В результате объединенных усилий разработка стандарта сосредоточилась на вопросах, которые являются общими для всех UNIX-подобных систем. В качестве признания расширения сферы охвата действия стандарта его название было изменено на Filesystem Hierarchy Standard или, для краткости, FHS.
Добровольцы, которые активно участвовали в создании стандарта, перечислены в конце настоящего документа. Этот стандарт представляет собой общую точку зрения перечисленных и других участников разработки.
7.3 Чем мы руководствовались
При разработке стандарта мы стремились достичь следующих целей:
- решить технические проблемы, и вместе с тем уменьшить трудности перехода на стандарт.
- сделать спецификацию в разумной степени стабильной.
- заслужить одобрение разработчиков, дистрибьюторов и других лиц, принимающих решения в группах разработчиков, и склонить их к участию в разработке стандарта.
- создать стандарт, который будет привлекательным для разработчиков различных UNIX-подобных систем.
7.4 Сфера действия стандарта
Этот документ задает спецификацию стандартной структуры каталогов файловой системы (или иерархию файловой системы), определяя требования к размещению каталогов и файлов, а также содержание некоторых системных файлов.
Стандарт создавался для использования системными интеграторами, разработчиками пакетов программного обеспечения и системными администраторами в процессе создания и поддержки 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. Поскольку стандарт представляет собой результат соглашения, к которому пришли все участники разработки, необходимо убедиться, что любая интерпретация его положений тоже представляет коллективное мнение. По этой причине может оказаться невозможным немедленно ответить на ваш запрос, если только содержание вопроса не было темой предшествующих дискуссий.
7.5 Благодарности
Разработчики стандарта FHS хотели бы поблагодарить разработчиков, системных администраторов и пользователей, которые внесли свой вклад в разработку настоящего стандарта. Мы благодарны всем тем, кто помогал писать, составлять и отлаживать настоящий стандарт.
Группа разработки стандарта (The FHS Group) также благодарит тех разработчиков ОС Linux, которые поддержали FSSTND, предшественника настоящего стандарта. Если бы они не продемонстрировали, что FSSTND был полезен (was beneficial), стандарт FHS никогда бы не был создан.
7.6 Участники разработки
| Brandon S. Allbery | |
| Keith Bostic | |
| Drew Eckhardt | |
| Rik Faith | |
| Stephen Harris | |
| Ian Jackson | |
| John A. Martin | |
| Ian McCloghrie | |
| Chris Metcalf | |
| Ian Murdock | |
| David C. Niemi | |
| Daniel Quinlan | |
| Eric S. Raymond | |
| Rusty Russell | |
| Mike Sangrey | |
| David H. Silber | |
| Thomas Sippel-Dau | |
| Theodore Ts'o | |
| Stephen Tweedie | |
| Fred N. van Kempen | |
| Bernd Warken | |
Таблица 7.6.1