1.0 Введение


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



В дальнейшем в качестве примеров UNIX буду использовать дистрибутив Debian/Ubuntu.

Как мы знаем из жизни, вся наша жизнь это решение возникающих перед нами проблем, возникновение новых проблем, в том числе и вытекающих из решения предыдущих и так далее, до бесконечности...

2.0 Проблема: как размещать файлы различных назначений в ОС


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

2.1 Первый вариант: сортировать файлы по пакетам


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

Плюсы:

  • Каждый производитель раскладывает в своей директории файлы так, как ему нужно.
  • Легко уста��авливать/удалять программы, скопировал или уничтожил директорию, и все дела.


Минусы:

  • Операционная система ищет исполняемые файлы или разделяемые библиотеки по списку, который находится в соответствующей переменной окружения. Например пути к исполняемым файлам перечислены в переменной окружения $PATH. Когда пакетов много, эти списки становятся реально огромными.
  • Есть еще одна веская причина, по которой желательно файлы сходного назначения разных размещать в одних и тех же местах. Дело в том, что из разных соображений, свойства директориев/файловых систем для файлов различных назначений должны отличаться. Это нужно, иногда из соображений безопасности, иногда из соображений оптимальной настройки системы. в UNIX есть возможность монтировать файловые системы в директории. Что это дает? Можно, например, смонтировать директорий для запускаемых бинарников смонтировать в режиме read only, и тогда никакая вредоносная программа туда ничего не сможет записать, а другую директорию смонтировать в режиме запрещающем запуск и тогда никто ничего с этой ФС ничего не сможет запустить. Файлы, которые должны изменяться (например файлы баз данных) располагаем на другой файловой системе, параметры которой можно тоже настроить оптимальным образом.


2.2 Второй вариант: сортировать файлы по функциям в системе


Плюсы:

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


Минусы:

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


3.0 Решение в UNIX-style


В UNIX-ах выбрано размещение по второму варианту. Т.е. файлы разных программ с одинаковым функциональным назначением, лежат в одном директории. Например исполняемые файлы разных пользовательских программ лежат в директории /usr/bin.

4.0 Проблемы, вытекающие из решения в UNIX-style, установка софта


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

5.0 Решение проблем: пакетные менеджеры


В дальнейшем будем называть менеджер пакетов МП.

Сформулированная в предыдущем разделе проблема в различных дистрибутивах UNIX/Linux решается при помощи работы по установке, удалению и хранению информации об установленном программном обеспечении специальной программе — менеджеру пакетов. В Debian/Ubuntu этим занимается dpkg. Вообще-то это только одна программа из целого набора программ, которые имеют отношение к этому. dpkg, это бэкенд, есть несколько фронтэндов, apt-get, aptitude, dselect, synaptic.

Что делает МП? По крайней мере в Debian/Ubuntu он занимается следующим:

  1. Установка пакетов.
  2. Удаление пакетов.
  3. Отслеживание зависимостей (при установке пакета вместе с пакетом устанавливать нужные для данного пакета другие пакеты)
  4. Установка пакетов по сети из удаленных репозитариев.
  5. Ведение локальной базы данных установленных пакетов.
  6. Ведение локальной базы данных доступных для установки пакетов в том числе и по сети.
  7. Обновление баз данных при изменении доступных пакетов и/или их версий.
  8. Корректная установка обновлений пакетов.
  9. Апгрейд всей системы.


Немало, как по вашему? И МП Debian/Ubuntu справляется со всем этим действительно неплохо.

Сам пакет обычно представляет собой архив файлов, описание пакета с несколькими полями, и скрипты, выполняемые при установке и удалении пакета. В Debian/Ubuntu файл пакета имеет расширение .deb .

6.0 Проблемы, связанные с пакетными менеджерами


Как известно, без проблем ничего не бывает. Использование МП тоже не исключение и приносит свои проблемы. Конечно МП решает гораздо больше проблем, чем приносит, но все-таки их нужно знать и с ними бороться. Итак, проблемы:

  1. Зависимости. Это плюс использования МП с одной стороны. С другой стороны отслеживание зависимостей это большая работа мэйнтенеров пакетов. На сегодня Debian входит 25113 пакетов. Одни пакеты требуют обязательной установки других, или наоборот, есть несовместимые пакеты. В результате получается большая и сложная система зависимостей. Все это добро нужно надо проверить.
  2. Иногда встречаются несовместимые комбинации пакетов.
  3. Иногда встречаются всякие хитрые кольцевые зависимости.
  4. В связи с большим количеством пакетов, которые нужно совместить друг с другом, иногда версии пакетов, входящие в дистрибутив устаревают.
  5. Часто в дистрибутиве присутствует ПО не той версии, которая нам нужна.
  6. Несмотря на такое большое количество пакетов, иногда нам нужен софт, которого вообще нет в дистрибутиве.
  7. Мы не можем устанавливать свой софт в директории, где хозяйничает МП, иначе наш софт может вступить в конфликт с софтом, устанавливаемым МП. Проще говоря мы можем затереть файлы, установленные МП, или наоборот.


7.0 Решение проблем, связанных с пакетными менеджерами, иерархия /usr/local


В последнее время практически весь нужный софт имеется в дистрибутиве в виде пакетов. Но все-таки рано или поздно как правило каждый пользователь/администратор встречается с необходимостью установки софта, который не входит в дистрибутив. Обычно встречаются такие варианты:

Проблема 1. Нужно перекомпилировать пакет с другими настройками.
Проблема 2. Нужного софта нет в дистрибутиве.
Проблема 3. В дистрибутиве не та версия, которую мы хотим.


Как быть? Как сделать это с наименьшим риском внести возмущения в работу системы? В наличии имеется несколько вариантов:

Проблема 1. Решение 1: Перекомпилировать пакет с другими настройками. (Это если нужно пакет с другими настройками). Опасности практически нет, хотя могут измениться зависимости по сравнению с пакетом, откомпилированом в дистрибутиве. Тут уже, ясный перец, за зависимости отвечаете Вы.
Проблемы 2,3 Решение 2. Собрать собственный пакет и установить в систему.
Проблемы 1,2,3 Решение 3 Установить софт собранный из исходников в иерархию /usr/local


С Решение 1 вроде все ясно, давайте рассмотрим подробнее Решение 2 и Решение 3.

Решение 2: Собрать собственный пакет и установить в систему.


Плюсы:

  1. Можно использовать все возможности МП, перечисленные в разделе 6.0.
  2. Если пакет предназначен для установки на несколько машин, можно воспользоваться сетевыми возможностями МП, создать свой репозиторий со своими пакетами и устанавливать/обновлять эти пакеты стандартным для МП способом.


Минусы:

  1. Использование всех или только части возможностей МП требует дополнительных усилий, иногда значительных. Если же ими не пользоваться, то какой смысл в использовании МП?
  2. Если не проверять свой пакет на совместимость, то весьма вероятна ситуация, когда ваш пакет вступит в конфликт с другими пакетами, причем конфликты могут быть самыми неожиданными.
  3. При массовом внедрении такого подхода (создание собственных пакетов), появляется возможность появления в интернете массы плохо оттестированных и плохо совместимых между собой пакетов, как было одно время с с RPM, не знаю, как у них с этим сейчас.


Debian Policy 2 (Ubuntu как производное от Debian руководствуется им тоже) прямо говорит две вещи:

  • ПО, устанавливаемое локально, устанавливается в иерархию /usr/local.
  • ПО, устанавливаемое локально должно быть в безопасности от переписывания при обновлении системы (имеется в виду обновление через МП).


Таким образом можно сделать вывод, что для ПО, которого нет в репозитарии, которое устанавливается локально на данную машину, или на небольшое количество машин, стандартный путь — установка в /usr/local.

Если ПО предназначено для распространения и установки в системы Debian/Ubuntu, лучший путь — упаковка его в .deb пакеты. НО! В этом случае вы отвечаете за зависимости, конфликты и обновления этого пакета.

8.0 Проблемы, связанные с иерархией /usr/local


  1. Как известно, любое решение приносит новые проблемы. Не исключение и решение, изложенное в предыдущем разделе. Все хорошо, пока мы установили в /usr/local один пакет, как только пакетов становится больше одного, появляется плохо управляемая куча файлов, с проблемами. описанными в разделе 4.0.
  2. Еще одна проблема, это проблема с директорией /usr/local/var Как известно, в директорию /var записываются файлы данных программ, которые могут изменятся во время работы программы (логи, PID-ы файлы БД и так далее). Часто
    /var делают на отдельной партиции, а сейчас у нас получилось, что изменяемые файлы попали в /usr/local/var.


9.0 Решение проблем, связанные с иерархией /usr/local, возможные воркэраунды


Решение проблемы 1. описано в моей статье 5, поэтому подробно описывать решение не буду. Вкратце, программы ставятся к��ждая в свою иерархию в директории /usr/local/stow, а затем, специальны менеджер (xstow), расставляет символьные ссылки на файлы программы.

Решение проблемы 2. Эту проблему придется решать руками. Если вы воспользовались программой stow, то можно, например, сделать директорию с уникальным именем в иерархии /var, например /var/local_var, а затем сделать ссылки на нее. Но это стоит делать только в том случае, если действительно есть такая необходимость.

10.0 Иерархия /opt


В иерархию /opt по Полиси 2 устанавливаю свой софт сторонние производители. Они устанавливают своё ПО в директории вида /opt/package или /opt/provider .

11.0 Проблемы пользователя, иерархия /home


Опять же по Полиси 2, файлы пользователей хранятся в иерархии /home, в директориях вида /home/username. Если говорить об установке ПО, то его можно устанавливать и сюда. причем как это делать, отдано на усмотрение пользователя.

В каких случаях это делать?

  • У пользователя нет прав администратора на компьютере.
  • Временно, "на посмотреть".
  • Собственные скрипты.


Я обычно использую смесь раскладки файлов "по директориям" и "по пакетам". Для ПО, которое работает постоянно, как правило, это мои скрипты, создаю директории /home/username/bin /home/username/etc /home/username/var. Софт, который просто хочу посмотреть или поиграться просто компилирую в директории /home/username/sw/softname и запускаю просто оттуда.

12.0 Другие применения иерархии /home


Часто применяют иерархию /home для размещения файлов, относящихся к крупным задачам, выполняющимся на компьютере. Например, разрабатывается проект с именем projectname. Тогда заводят в системе пользователя с именем projectname и все, к нему относящееся помещают в директорию /home/projectname

13.0 Другие ОС


Однажды Вовочкина мама сказала папе:
"тебе не кажется, что нашему Вовочке уже
пора рассказать про секс?"
Папа подумал, и ответил:
"наверное ты права, только неудобно как-то."
Мама: "Ну расскажи на примере бабочек."
Папа позвал Вовочку и говорит:
"Вовочка, помнишь мы с тобой были в
публичном доме?"
"Помню."
"Ну так вот: у бабочек все точно так же."


Анекдот


FreeBSD


В ОС FreeBSD в принципе все также, с небольшими отличиями. Файлы базовой системы там находятся как и у Linux семейства Debian/Ubuntu в основной иерархии. Бинарным пакетам там соответствуют два понятия, пакеты и порты.

Пакеты это примерно то же самое, что и пакеты в Debian/Ubuntu. В качестве пакетного менеджера там используется набор команд для работы с пакетами (и портами).

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

Как пакеты, так и порты устанавливаются в иерархию /usr/local.

Точно так же, как и в Debian/Ubuntu может встретится ситуация, когда для софта нет ни пакета ни порта. Тогд��, естественно, нужно устанавливать софт из исходников. Для этого можно или сделать порт для этого софта, или просто скомпилировать и установить исходники в иерархию /usr/local. Конечно, поскольку в FreeBSD там устанавливается много софта, нужно быть внимательным, т.к. вероятность конфликтов из-за этого возрастает.

Ну и возвращаясь к методам, описанным в статье 5, думаю, что если Вы не делаете своего порта, для поддержания порядка, можно использовать программу xstow. Хотя у BSD-истов могут быть свои излюбленные методы, неизвестные мне, пусть знающие товарищи меня поправят, если я ошибаюсь.

Семейство Windows


В ОС семейства Windows, для размещения софта, как правило применяется подход, когда для каждого пакета ПО — своя иерархия. Наблюдаются некоторые подвижки в сторону раскладки файлов по назначениям, но этому мешают:

— Отсутствие единого дерева файловой системой (буквы, обозначающие партиции, C:, D: и т.д.).
— Традиция.
— Требования совместимости с наработанным софтом.

Заключение


Надеюсь статья будет полезной. В принципе можно бы было в другой статье более подробно разобрать назначение других директорий и иерархий ФС UNIX/Linux.

Список использованных сокращений


.deb Расширение файлов пакетов ПО для Debian/Ubuntu
dpkg dpkg — это программное обеспечение, являющееся основой системы управления пакетами в Debian.
PID Идентификатор процесса
RPM Red Hat Package Manager — менеджер пакетов Red Hat
БД База данных
МП Менеджер пакетов
ОС Операционная система
ПО Программное обеспечение
репозитарии Хранилище софта с доступом при помощи МП
ФС Файловая система


Литература


1. Стандартная иерархия файловой системы Linux (File System Hierarchy Standard)
2. Filesystem Hierarchy Standard (Дополнение к Debian Policy)
3. http://ru.wikipedia.org/wiki/RPM
4. http://ru.wikipedia.org/wiki/Dpkg
5. Linux: Установка программ не входящих в дистрибутив при помощи менеджера xstow
6. man hier