Разберемся со всеми папками 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 / без создания определенных папок для данной программы.

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

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

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

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

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

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

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

/usr/sbin двоичные файлы — это общие инструменты системного администратора, в которых вы можете, по крайней мере, перейти в однопользовательский режим и смонтировать все свои тома. Им разрешено быть динамически связанными.

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

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

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

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

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

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

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

Я понимаю значение каталогов (исходя из опыта работы с Debian GNU Linux) так:

Первое различие: s для суперпользователя

s перед bin каталог указывает, что он содержит инструменты, которые обычно полезны только администраторам. Обратите внимание, что, например, ifconfig тоже принадлежит к этой категории, и мне нравится вызывать ifconfig как обычный пользователь (чтобы проверить, есть ли у меня IP-адрес / подключение к сети), что делает это различие не таким сложным, как может показаться.

Второе отличие: local для «Локальных данных»

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

Спорный вопрос, является ли /usr/local должен переопределить существующие файлы из обычных /usr структуру, см. Опасно ли иметь / usr / local / bin перед / usr / bin в PATH? для получения некоторых подробностей об этом.

Третье отличие: высший уровень /bin и /sbin каталоги.

В Debian есть так называемый UsrMerge. Раньше была разница в том, что /bin и /sbin были доступны в процессе загрузки ранее (подумайте о /usr находясь на сетевом устройстве или другом разделе, RAID и т. д.), но в настоящее время немногие системы Linux хорошо загружаются без /usr поэтому я хотел бы рассмотреть различие между верхним уровнем и /usr каталоги, которые в значительной степени представляют исторический интерес для Linux.

Напоследок: достоинства и проблемы «разлетающихся» файлов.

На этот вопрос действительно нет «единственно верного» ответа. Преимущества распределенной файловой системы Linux следующие:

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

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

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

• Из-за стандартизации FHS документация также находится в центральных местах, что позволяет использовать такие системы, как man, info и вспомогательные файлы README для правильной работы.

• Проще полагаться на то, что программа устанавливается в определенное место. Все пишут #!/bin/sh -e или что-то подобное в начале скрипта, и это просто работает. Рассмотрим систему, в которой оболочка переходит в другой каталог: как узнать, какое имя она примет? Если интересно, проверьте различные способы установки Perl или LaTeX в Windows, чтобы увидеть, насколько это может быть сложно …

К настоящему моменту я обнаружил следующие недостатки:

• Обычно труднее запускать приложения «портативно» в смысле «переносимых приложений для Windows». В Linux не так просто скопировать программу на другой компьютер … нужно иметь пакет (который требует прав root) или иметь дело с LD_LIBRARY_PATH указывать приложениям на разные пути поиска требуемых библиотек.

• Установка нескольких версий одной и той же программы должна явно поддерживаться, тогда как в системах с «одним каталогом на программу» это часто не представляет проблемы.

• Управление файлами без диспетчера пакетов подвержено ошибкам (как уже упоминалось).