В статье рассказывается о разработанном в рамках проекта Open Source стандарте на структуру каталогов UNIX-подобных операционных систем (подразумеваются Linux и BSD-системы).

Одно из первых понятий, с которыми сталкивается любой пользователь компьютера - это, безусловно, понятие файловой системы. При этом пользователь видит только одну сторону файловой системы, а именно, иерархическую структуру (или дерево) каталогов и файлов. Фактически все каталоги тоже являются файлами, и с точки зрения механизма хранения файлов на диске все файлы, включая каталоги, организованы одинаково [1]. Но для человека работать с "линейным" списком, содержащим тысячи файлов, было бы крайне неудобно, поэтому и было изобретено понятие "каталога", чисто логического образования, позволяющего дать каждому файлу понятное для человека "полное имя", определяющее некий "путь" к файлу в единой структуре каталогов.

Поскольку структура каталогов - понятие чисто логическое и к реальным механизмам работы с файлами не имеет отношения, изначально никаких особых требований на вид логического дерева каталогов со стороны операционной системы не предъявляется. И в силу этого каждый конкретный вариант операционной системы, в частности, каждый из дистрибутивов Linux, мог бы строить это дерево по-своему. Легко понять, что это могло бы привести к возникновению больших проблем в работе программного обеспечения от различных разработчиков, к несовместимости и непереносимости программ, установка новых программ в систему и работа большинства приложений были бы очень затруднены, поскольку масса времени уходила бы на поиск нужных файлов. Подчинение же структуры каталогов определенным стандартам позволяет обеспечить совместимость программного обеспечения, разрабатываемого разными группами авторов и в рамках различных дистрибутивов. Поэтому группой энтузиастов (как все, что создается в рамках движения Open Source) был разработан стандарт на структуру каталогов для UNIX-подобных ОС, так называемый стандарт иерархии файловых систем (Filesystem Hierarchy Standart или кратко FHS).

Работа по созданию этого стандарта была начата в августе 1993 года с попытки упорядочить структуру файлов и каталогов операционной системы Linux. Вначале стандарт назывался проектом стандартов файловой системы - Filesystem Standarts project (FSSTND), и был ориентирован только на систему Linux. Его первая версия была выпущена 14 февраля 1994 года. Последующие редакции были выпущены 9 октября 1994 и 28 марта 1995 года. В разработке стандарта принимало участие большое количество добровольцев, но главным организатором был Дэниел Квинлан (Daniel Quinlan).

В начале 1995 года с участием сообщества разработчиков системы BSD была поставлена цель создания более общей версии FSSTND, предназначенной не только для Linux, но и для других UNIX-подобных операционных систем. В результате объединенных усилий разработка стандарта сосредоточилась на вопросах, которые являются общими для всех UNIX-подобных систем, включая операционные системы типа 4.4BSD. Учитывая расширение сферы действия стандарта, он был переименован в Filesystem Hierarchy Standard или, для краткости, FHS. Естественно, что "настоящие" UNIX-системы, созданные задолго до появления этого стандарта, ему не соответствуют. Однако FHS учитывает все положительные качества, присущие BSD и другим системам в части поддержки различных архитектур и учета требований работы в гетерогенных сетях. На момент написания этой статьи последней версией стандарта FHS является версия 2.2, которая была выпущена 24 мая 2001 года. Полный исходный текст этого стандарта можно найти в Интернет на сайте http://www.pathname.com/fhs/, а его русский перевод - по адресу http://linux-ve.net/MyLDP/file-sys/fhh-2.2-rus/index.html.

При разработке стандарта FHS его авторы стремились создать в первую очередь справочник, а не учебник по построению структуры каталогов. Стандарт создавался для использования системными интеграторами, разработчиками пакетов программного обеспечения и системными администраторами в процессе создания и поддержки UNIX-совместимых файловых систем.

В основу разработки стандарта были положены следующие соображения.

Во-первых, учитывалось, что в UNIX-подобных ОС структура каталогов представлена в виде единого дерева. Отдельные "ветви" этого дерева могут располагаться на разных носителях, или в разных файловых системах, причем эти файловые системы могут быть разными по своей внутренней организации - на одном носителе это файловая система ext2fs, на другом - vfat, и так далее. Разработчики стандарта стремились обеспечить оптимальное размещение файлов в разных файловых системах с тем, чтобы оптимизировать процессы загрузки, последующего функционирования и возможного обновления системы.

Во-вторых, любая UNIX-система (в том числе и Linux) - система сетевая, и эти файловые системы и соответствующие носители могут физически располагаться даже на разных компьютерах. Поэтому при размещении отдельных файлов в различных частях файловой структуры надо учитывать, что некоторые файлы должны быть доступны с других компьютеров в сети (быть разделяемыми), а к другим файлам доступ по сети необходимо ограничить. Выделение группы разделяемых файлов позволяет экономить общее дисковое пространство. Группа неразделяемых файлов вычленяется как по соображениям безопасности, так и просто потому, что эти файлы определяют локальную конфигурацию системы и поэтому нужны только на данном компьютере. Например, пользовательские каталоги могут (а часто и должны) быть разделяемыми, а файлы настройки процедур загрузки системы должны быть неразделяемыми.

В третьих, файлы делятся на статические (неизменяемые) и изменяемые. К числу статических файлов относятся исполняемые файлы, библиотеки, документация и другие файлы, изменять которые может только администратор системы. Для остальных пользователей эти файлы должны быть доступны только по чтению. Изменяемые файлы - это те, которые любой пользователь может менять без привлечения администратора.

В таблице 1 приведены несколько примеров того, какие каталоги (точнее, файлы каких каталогов) относятся к каждому из 4 классов, образующихся при разбиении всего множества файлов по этим двум критериям.

Таблица 1. Пример выделения классов файлов

Выделение этих 4 классов файлов помогает понять те принципы, на которых строится стандартная структура каталогов, предлагаемая стандартом FHS. Ее описание начнем, естественно, в описания структуры корневого каталога, который имеет имя "/".

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

Стандарт FHS предлагает создать в корневом каталоге следующие подкаталоги

Таблица 2. Основные подкаталоги корневого каталога

Это не означает, что все содержимое перечисленных каталогов должно размещаться в корневой файловой системе. Указанные каталоги могут являться просто точками монтирования для других файловых систем или ссылками на такие системы. Более того, в стандарте явно рекомендуется размещать в каталогах /usr, /opt и /var такие файлы, которые могут располагаться в других разделах диска или в других файловых системах. Впрочем, давайте отложим рассмотрение вопроса о том, как разместить каталоги по разным файловым системам, до последнего раздела настоящей статьи, а пока вернемся к рассмотрению тех требований, которые стандарт FHS предъявляет к корневому каталогу.

В соответствии с требованиями стандарта приложения не должны создавать файлов и каталогов или требовать наличия каких-то специальных файлов и каталогов (кроме перечисленных выше) в корневой директории. Существует несколько причин, по которым это запрещено:

• размер корневой файловой системы желательно сохранять по возможности малым из соображений безопасности и удобства использования;

• если придерживаться данного соглашения, проще решаются проблемы монтирования других файловых систем, расположенных на других устройствах;

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

Обратите внимание на то, что некоторые подкаталоги корневого каталога помечены значком (optional). Это означает, что стандарт не требует обязательного наличия таких каталогов в системе. Но уж если они существуют, то должны размещаться в корневом каталоге (но не обязательно в корневой файловой системе).

А теперь последовательно рассмотрим назначение каждого из основных подкаталогов корневого каталога.

Каталог /bin

Каталог /bin содержит команды, которые могут использоваться как системным администратором, так и рядовыми пользователями, причем только те команды, которые необходимы, когда никакая другая файловая система, кроме корневой, еще не смонтирована (например, в однопользовательском режиме). В этом каталоге могут также содержаться команды, которые используются не напрямую пользователем, а включаются в сценарии оболочки (скрипты). Исполняемые файлы, которые не так важны, чтобы быть расположенными в каталоге /bin, должны размещаться в каталоге /usr/bin. Те утилиты, которые необходимы только рядовым пользователям (файлы системы X Window, chsh, и так далее) обычно не так необходимы, чтобы размещаться в корневой файловой системе (в корневом разделе диска).

В /bin должны иметься следующие команды или символические ссылки на соответствующие команды:

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

Следующие программы или символические ссылки на программы должны находиться в каталоге /bin, если только соответствующие пакеты установлены в системе:

csh, ed, tar, cpio, gzip, gunzip, zcat, netstat, ping.

В каталоге /bin не должно быть подкаталогов.

Каталог /boot

Этот каталог содержит все, что необходимо в процессе загрузки, исключая конфигурационные файлы и установщик карты загрузки (the map installer). Таким образом, в /boot хранятся данные, которые используются до того, как ядро начинает исполнять программы пользователя. Здесь же находятся резервные сохраненные копии главной загрузочной записи (master boot sectors) и другие данные, которые не подлежат прямому редактированию.

Ядро операционной системы должно быть расположено либо в корневом каталоге /, либо в /boot . Программы, необходимые загрузчику для организации загрузки файлов, должны быть расположены в /sbin. Конфигурационные файлы загрузчика должны размещаться в /etc.

Каталог /dev

Каталог /dev - это место расположения специальных файлов устройств. На случай, если потребуется создавать файлы устройств вручную, каталог /dev должен содержать команду MAKEDEV, которая может создать файл устройства в случае необходимости.

Каталог /etc

Каталог /etc содержит конфигурационные файлы и каталоги, специфичные для данной конкретной системы. В каталоге /etc не должно быть бинарных файлов. В соответствии со стандартом FHS этот каталог в обязательном порядке должен содержать подкаталог /opt, в котором должны размещаться подкаталоги с конфигурационными файлами отдельных пакетов и приложений. Для каждого установленного пакета <package> должен создаваться конфигурационный каталог /etc/opt/package. Надо отметить, что не все дистрибутивы следуют этому правилу: часто конфигурационные каталоги пакетов размещаются непосредственно в /etc.

Следующие каталоги и файлы либо символические ссылки на них должны быть расположены в /etc, если соответствующие пакеты установлены в системе:

Таблица 3. Подкаталоги и файлы в каталоге /etc

Файл mtab не соответствует неизменяемой природе файлов, размещенных в /etc; он помещен в данный каталог в виде исключения по историческим причинам. Впрочем, в некоторых системах он является символической ссылкой на /proc/mounts, в этом случае делать исключение не требуется.

Каталог /etc/X11 - это место размещения всех конфигурационных данных для X11, специфичных для данного хоста. Эта директория необходима для того, чтобы обеспечить локальное управление системой X Window в том случае, когда файловая система /usr монтируется только на чтение.

Следующие файлы или символические ссылки на соответствующие файлы должны находиться в /etc/X11:

• Xconfig - Конфигурационный файл для ранних версий XFree86

• XF86Config - Конфигурационный файл для XFree86 версий 3 и 4

• Xmodmap - Глобальный файл модификации клавиатуры в X11

Среди подкаталогов в /etc/X11 могут находиться отдельные подкаталоги с конфигурационной информацией для xdm и других программ (например, для оконных менеджеров), которые в такой информации нуждаются.

Каталог /home

В небольших системах каждый домашний каталог пользователя является одним из непосредственных подкаталогов каталога /home, таких как /home/smith, /home/torvalds, /home/operator и так далее. В больших системах (особенно когда каталоги /home являются разделяемыми между многими хостами посредством NFS) полезно объединить домашние каталоги в группы, введя подкаталоги групп такие как /home/staff, /home/guests, /home/students и так далее. Но как бы то ни было, структура домашних каталогов различается от хоста к хосту. Следовательно, никакая программа не должна полагаться на какие-то предположения о структуре домашних каталогов.

Каталог /lib

Каталог /lib содержит те разделяемые библиотеки, которые необходимы для загрузки системы и запуска команд, расположенных в каталогах /bin и /sbin.

По крайней мере, один из файлов, соответствующих каждому из следующих шаблонов, должен найтись в данном каталоге (это могут быть либо реальные файлы, либо символические ссылки):

• libc.so.* - Динамически подсоединяемые библиотеки C;

• ld* - Загрузчик/линковщик времени выполнения.

По историческим причинам, если препроцессор языка Си установлен, файл /lib/cpp должен быть ссылкой на него.

Не должны располагаться в /lib разделяемые библиотеки, которые необходимы только исполняемым файлам, расположенным в /usr (таким, как бинарные файлы системы X Window). В частности, библиотека libm.so.* может быть расположена в /usr/lib, если она не требуется никаким программам из /bin или /sbin.

Более одного варианта каталога /lib может существовать в системах, поддерживающих более одного формата исполняемых файлов (например, 32-х и 64-х разрядные форматы), при этом для каждого формата требуется свой отдельный вариант разделяемых библиотек (которые могут называться /lib32 и /lib64).

Каталог /mnt

Эта директория предназначена для того, чтобы системный администратор мог временно монтировать файловые системы по мере необходимости. Содержимое этого каталога индивидуально для каждой системы и не должно никаким образом влиять на работу запускаемых программ.

Этот каталог не должен использоваться программами инсталляции ПО; для создания и хранения временных файлов на этапе инсталляции должны использоваться временные каталоги, не используемые системой

Каталог /opt

Стандарт FHS резервирует каталог /opt для установки дополнительных пакетов программного обеспечения. Предполагается, что любой пакет, который устанавливается в каталог /opt, должен размещать свои статические файлы в отдельной каталоговой структуре /opt/<package>, где <package> - название соответствующего пакета программного обеспечения.

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

Каталоги /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. Специфичные для хоста конфигурационные данные должны устанавливаться в /etc/opt.

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

Дистрибутивы могут устанавливать программное обеспечение в каталог /opt, но не должны модифицировать или удалять ПО, установленное местным системным администратором, без разрешения этого самого администратора.

Каталог /root

Каталог /root - это домашний каталог суперпользователя. Он может быть задан разработчиком или определен при инсталляции системы, но рекомендуемое место его расположения по умолчанию - корневая файловая система.

В стандарте FHS подчеркивается, что бюджет суперпользователя должен использоваться исключительно для системного администрирования и его не рекомендуется использовать для выполнения задач, которые могут быть выполнены непривилегированным пользователем. По этой причине не стоит размещать подкаталоги для почты и других приложений в домашнем каталоге пользователя root. Почта для таких администраторских ролей как root, postmaster и webmaster должна пересылаться соответствующему пользователю.