Каковы значения /usr /sbin, /usr /local /sbin и /usr /local /bin?

Question

Давайте разберемся со всеми папками bin и sbin (из стандарта иерархии файловой системы):

• /bin предназначен для двоичных файлов системного уровня
• /sbin предназначен для других двоичных файлов системного уровня, в основном для загрузчика и системных администраторов.
• /usr/bin для несущественных двоичных файлов
• /usr/sbin - это то место, где начинается беспорядок - не необходимые инструменты для системных администраторов? Что это значит? Для экспериментов?
• /usr/local/bin - нет слов об этой папке
• /usr/local/sbin - локально установленные программы системного администрирования. Снова? Как насчет /usr/sbin?

Поэтому возникает вопрос: почему существует так много каталогов и что означает значения /usr/sbin , /usr/local/sbin и /usr/local/bin?

Многие программы распространяются через архивы, и мы должны создавать их из исходного кода. Обычно у них есть make-файл, так что это довольно просто. Этот процесс включает в себя создание файлов в каталогах usr/local/lib, usr/local/bin ... usr/local/ независимо от того, какие файлы не созданы для данной программы.

Почему это так?

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

Answer 1

1. Структура каталогов

Это должно быть отражено в стандарте иерархии файловой системы (2.3 PDF)

/bin/       Essential command binaries that need to be available in single user mode;
            for all users, e.g., cat, ls, cp

/sbin/      Essential system binaries, e.g., init, ip, mount.

/usr/bin/   Non-essential command binaries (not needed in single user mode); 
            for all users

/usr/sbin/  Non-essential system binaries, e.g. daemons for various network-services.

/usr/local/ Tertiary hierarchy for local data, specific to this host. 
            Typically has further subdirectories, e.g., bin/, lib/, share/

2. Монтаж

Я использую менеджер пакетов везде, где это возможно (например, yum или apt-get). Это возможно для очень большого числа приложений, в некоторых случаях вам может понадобиться добавить репозиторий. Моим вторым выбором были бы пакеты более низкого уровня, такие как RPM, и компиляция из исходного кода была бы моим последним средством (но некоторые люди предпочитают это)

Некоторые менеджеры пакетов могут устанавливать из RPM (например, yum install oddity.rpm)

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

Тогда ваша проблема сводится, например, к yum remove packagename

Альтернатива - хранить хорошую документацию обо всех предпринятых действиях сисадмина (в любом случае я веду журнал в текстовом файле).

Answer 2

Материал во всех каталогах */sbin полезен только для системных администраторов. Вы можете держать их вне своего PATH, если вы обычный пользователь.

Разные каталоги не имеют большого смысла, если у вас есть один компьютер с Unix на одном диске, но имеют больше смысла, если у вас большая система и разные разделы. Помните, что многие из этих привычек были созданы в 80-х и 90-х годах, когда системы были немного другими.

/sbin имеет тенденцию быть очень маленьким. Это утилиты, которые вам нужны, когда вы на самом деле находитесь в безопасности. Вы бы поместили это в минимальный корневой раздел с /root и /lib. Вещи в /sbin раньше были статически связаны, так как если ваш раздел /usr скрыт, любые динамически связанные приложения бесполезны. fsck здесь и статически связан. Если у вас есть зависимость от /usr, очевидно, вы не можете fsck /usr /. Конечно, если корневой раздел скрыт, вы очень испорчены. Вот почему это такой маленький раздел - уменьшите шансы плохого дискового блока, используя здесь очень мало блоков.

/usr/sbin binaries - это общие инструменты sysadmin, где вы можете по крайней мере перейти в однопользовательский режим и смонтировать все свои тома. Они могут быть динамически связаны.

Отдельные разделы для /sbin (ну, /sbin on / partition) и / usr также имеют больше смысла, когда вы помните, что резервное копирование было очень дорогим как по времени, так и для ленты. Если бы они были на отдельных разделах, вы могли бы запланировать их по-другому.

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

Опять же, многое стало более понятным на больших машинах в сетевой среде на управляемых машинах с несколькими томами, в меньшей степени - на одной машине Linux в одном корневом разделе.

Answer 3

У вас действительно должен быть ваш второй вопрос, отдельный вопрос здесь, на Superuser. Это не связано с первым.

Да, иметь файлы повсюду - отстой. Вот почему существует множество упаковочных решений. RedHat создал RPM, который используется везде. У Соляриса был их формат пакета. У HP/UX были свои, и есть много других форматов пакетов. Храните вещи в нужных местах (/usr/bin, /usr/lib) по мере необходимости, но допускайте легкое добавление и удаление.

Для источника раньше были инструменты, которые позволяли бы вам настраивать и устанавливать в подкаталоге /usr /local, и он обрабатывал символические ссылки на /usr /local /bin для вас. Поскольку широкое распространение получили пакетные инструменты, в этом нет необходимости, и я забыл их названия.

Некоторые люди любят устанавливать в /opt /packagename и хранить там все вместе. Хорошо: все находится в одном каталоге, а удаление - это rm -rf /opt/packagename . Недостатками этого являются добавление /opt /packagename /bin к каждому PATH и тот факт, что люди обычно не помещают /opt в отдельный раздел, а вы заполняете корневой раздел.

Answer 4

Чтобы ответить на ваш второй вопрос:
Обычно программы распространяются с помощью так называемого менеджера пакетов. Диспетчер пакетов обычно выбирает двоичные пакеты (программное обеспечение, скомпилированное для определенной платформы) и разбрасывает их по каталогам (есть некоторые, кто загружает исходный код, компилирует его на вашем компьютере и устанавливает его). Таким образом, менеджер пакетов знает, где находятся файлы, принадлежащие определенной "программе" (пакету), и когда вы хотите удалить пакет, менеджер пакетов позаботится об очистке всего.
Даже когда вы компилируете исходный код самостоятельно

make

и установить его с

make install

вы обычно можете сделать

make uninstall

который удаляет файлы из файловой системы.