Давайте разберемся со всеми папками bin и sbin (из стандарта иерархии файловой системы):
/binдля двоичных файлов системного уровня/sbinпредназначен для других двоичных файлов системного уровня, в основном для загрузчика и системных администраторов/usr/binдля необязательных двоичных файлов/usr/sbin- вот тут и начинается бардак - не необходимые инструменты для системных администраторов? Что это значит? Для экспериментов?/usr/local/bin- ни слова об этой папке/usr/local/sbin- локально установленные программы системного администрирования. Опять? А как насчет/usr/sbin?
Итак, вопрос: почему существует так много каталогов и что означают /usr/sbin, /usr/local/sbinи /usr/local/bin?
Многие программы распространяются через архивы, и нам приходится собирать их из исходного кода. Обычно у них есть makefile, так что это довольно просто. Этот процесс включает создание файлов в usr/local/lib, usr/local/bin... usr/local/whatever без создания определенных папок для данной программы.
Почему это так?
Я думаю, что это неправильно, потому что если нам нужно удалить программу, нам придется вручную удалить каждый ее файл, если создатель программы об этом не позаботился.
решение1
1. Структура каталога
Это должно быть рассмотрено вСтандарт иерархии файловой системы (2.3 PDF)
/bin/ Основные двоичные файлы команд, которые должны быть доступны в однопользовательском режиме;
для всех пользователей, например, cat, ls, cp
/sbin/ Основные системные двоичные файлы, например, init, ip, mount.
/usr/bin/ Необязательные двоичные файлы команд (не требуются в однопользовательском режиме);
для всех пользователей
/usr/sbin/ Необязательные системные двоичные файлы, например, демоны для различных сетевых служб.
/usr/local/ Третичная иерархия для локальных данных, специфичных для этого хоста.
Обычно имеет дополнительные подкаталоги, например, bin/, lib/, share/
2. Установка
Я использую менеджер пакетов везде, где это возможно (например, yum или apt-get). Это возможно для очень большого количества приложений, в некоторых случаях вам может потребоваться добавить репозиторий. Моим вторым выбором были бы пакеты более низкого уровня, такие как RPM, а компиляция из исходников была бы моим последним средством (но некоторые люди предпочитают это)
Некоторые менеджеры пакетов могут устанавливаться из RPM-пакетов (например yum install oddity.rpm, )
Если вы компилируете из исходного кода, то, вероятно, не составит большого труда создать собственный пакет, чтобы установщик системы знал, что вы сделали.
Тогда ваша проблема сводится к следующему:yum remove packagename
Альтернативой является ведение хорошей документации обо всех действиях системного администратора (я в любом случае веду журнал в текстовом файле).
решение2
Вещи во всех каталогах */sbin, как правило, полезны только системным администраторам. Вы можете убрать их из PATH, если вы обычный пользователь.
Различные каталоги не имеют особого смысла, если у вас есть одна машина unix на одном диске, но имеют больше смысла, если у вас большая система и разные разделы. Помните, что многие из этих привычек были созданы в 80-х и 90-х годах, когда системы были немного другими.
/sbinкак правилооченьsmall. Это утилиты, которые вам нужны, когда вы действительно влипли. Вы бы поместили это в минимальный корневой раздел с /root и /lib. Раньше все в /sbin было статически скомпоновано, так как если ваш раздел /usr влип, любые динамически скомпонованные приложения бесполезны. fsck здесь и статически скомпонован. Если у вас есть зависимость от /usr, очевидно, вы не можете fsck /usr/. Конечно, если корневой раздел влип, вы очень сильно облажались. Вот почему это такой маленький раздел — уменьшите вероятность плохого блока диска, используя здесь очень мало блоков.
/usr/sbinБинарники — это общие инструменты системного администратора, с помощью которых вы можете по крайней мере перейти в однопользовательский режим и смонтировать все свои тома. Их можно динамически связывать.
Отдельные разделы для /sbin (ну, /sbin на разделе /) и /usr также имеют больше смысла, если вспомнить, что резервное копирование было очень дорогим и по времени, и по ленте. Если бы они были на отдельных разделах, вы могли бы планировать их по-разному.
/usr/localможет быть сетевой файловой системой. Поэтому локально написанные инструменты системного администратора, которые могут быть общими для многих машин, иногда помещаются в /usr/local/sbin. Очевидно, что никакие утилиты для исправления сети не могут попасть туда.
Опять же, многие вещи имели больше смысла на больших машинах в сетевой среде на управляемых машинах с несколькими томами, и меньше — с одной машиной Linux на одном корневом разделе.
решение3
Вам действительно стоит задать свой второй вопрос отдельным вопросом здесь, на 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 на отдельный раздел, и вы заполняете корневой раздел.
решение4
Отвечая на ваш второй вопрос:
обычно программы распространяются с так называемымменеджер пакетов. Менеджер пакетов обычно извлекает бинарные пакеты (программное обеспечение, скомпилированное для определенной платформы) и разбрасывает их по каталогам (есть некоторые, которые скачивают исходный код, компилируют его на вашей машине и устанавливают). Таким образом, менеджер пакетов знает, где находятся файлы, принадлежащие определенной "программе" (пакету), и когда вы хотите удалить пакет, менеджер пакетов позаботится об очистке всего.
Даже когда вы компилируете исходный код самостоятельно с помощью
make
и установите его с помощью
make install
обычно вы можете сделать
make uninstall
который удаляет файлы из файловой системы.