Еще одно мнение о разнице между bin, sbin, usr/bin, usr/sbin
Недавно я обнаружил вот такую статью: Разница между bin, sbin, usr/bin, usr/sbin. Хотелось бы поделиться своим взглядом на стандарт.
Содержит команды, которые могут использоваться как системным администратором, так и пользователями, но которые необходимы, когда не смонтированы никакие другие файловые системы (например, в однопользовательском режиме). Он также может содержать команды, которые косвенно используются скриптами.
Там ожидается присутствие таких команд:
Можно сделать симлинки на /usr, но хотя во времена systemd /usr на отдельном устройстве не встречается, его еще можно встретить на встраиваемой системе, светофоре, кофемолке и PDP-11 обслуживающем важный прибор в одной из лабораторий Академии Наук.
Утилиты, используемые для системного администрирования (и другие команды только для root), /sbin содержит двоичные файлы, необходимые для загрузки, восстановления, восстановления и/или восстановления системы в дополнение к двоичным файлам в /bin. Программы, выполняемые после того, как /usr монтируется (когда проблем нет), обычно помещаются в /usr/sbin. Локально установленные программы системного администрирования должны быть помещены в /usr/local/sbin.
fastboot, fasthalt, fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update.
Один из способов защиты системы от шаловливых рук юзеров — это запрет запуска этих утилит кому-попало, установкой атрибута x.
К тому же, замена /bin и /sbin на копии из архива (одинакового для всех однотипных систем) является быстрым способом починки систем без пакетного менеджера.
/usr/bin
Тут всё просто. Однотипные команды, одинаковые для всех серверов/кофемолок компании. И сам /usr может разворачиваться одинаковым для разных ОС (для /bin и /sbin такое как правило не работает), это архитектурно независимые программы. Может содержать линки на интерпретаторы perl или python, которые лежат в /opt или еще где-то в сети.
/usr/sbin
Тоже самое, что /usr/bin, но для использования только админами.
/usr/local/bin и /usr/local/sbin
Одна из важнейших локаций. В отличие от остального, /usr не может быть одинаковой для всей организации. Тут находятся ОС-зависимые, hardware-зависимые и просто программы, которые не на всех устройствах нужны. При синхронизации /usr на машинах, /usr/local требуется исключать.
/home/$USER/bin
Тут случай аналогичный с /usr/local, только лежат программы специфичные для конкретного пользователя. Можно переносить (или синхронизировать) на другую машину при переезде пользователя. То, что нельзя переносить складывается в /home/$USER/.local/bin. Можно использовать local без точки. /home/$USER/sbin по понятным соображениям отсутствует.
Источник
Что такое / usr / local / bin?
До сегодняшнего дня я использовал терминал в ограниченной степени для перемещения и извлечения каталогов и изменения даты файлов с помощью touch команды. Я понял весь объем терминала после установки забавного скрипта на Mac и наличия chmod 755 файла, чтобы впоследствии его можно было выполнить.
Я хотел бы знать, что /usr/local/bin , однако. /usr/ Я полагаю, это пользователь компьютера. Я не уверен, почему /local/ там. Очевидно, это означает локальный компьютер, но поскольку он находится на компьютере (или сервере), действительно ли это будет необходимо? Не было /usr/bin бы хорошо?
А что есть /bin ? Почему эта область обычно используется для установки скриптов на терминал?
/usr/local/bin для программ, которые может запустить обычный пользователь.
- /usr/local Иерархия для использования системного администратора при установке программного обеспечения на местном уровне.
- Он должен быть защищен от перезаписи при обновлении системного программного обеспечения.
- Он может использоваться для программ и данных, которые являются общими для группы хостов, но не найдены в /usr .
- Локально установленное программное обеспечение должно быть размещено в /usr/local / usr, а не в том случае, если оно устанавливается для замены или обновления программного обеспечения /usr .
Этот источник помогает объяснить стандарт иерархии файловой системы на более глубоком уровне.
/ usr /, я полагаю, является пользователем компьютера.
Unix начинал как многопользовательская операционная система, поэтому это не «пользователь», это « пользователи », множественное число.
До выпуска AT & T Unix System V Release 4 (SVR4) в 1988 году с инструментами управления пользователями, в которых /home по /usr умолчанию создавались домашние каталоги пользователей , было обычное местоположение. Directory Возможно, ваш $HOME каталог находился /usr/jfw в окне System III .
/usr содержится также то , как сейчас, /usr/bin , /usr/lib и т.д. Опыт показал , что сегрегация домашних каталогов была хорошая практикой управления системой, так и с /home изменением политики в SVR4 он оставил позади все мы теперь думаем, как принадлежащие в /usr .
/usr у него все еще была веская причина удержать это имя: остались те файлы, которые не должны были быть доступны, пока система не загрузилась достаточно далеко, чтобы поддерживать нормальное интерактивное использование. То есть, то, что осталось позади, были ориентированные на пользователя части ОС. Это означало, что он /usr мог находиться на другом физическом томе, что было хорошо во времена 92 МБ жестких дисков размером со стиральные машины .
Ранние системы Unix старались не допускать доступа к файлам ядра ОС, /usr чтобы вы могли по-прежнему загружаться в однопользовательском режиме2, даже если /usr том был по каким-то причинам отключен. Корневой том содержал достаточно инструментов, чтобы вернуть /usr том в оперативный режим .
Несколько ароматов Unix в настоящее время не игнорировать этот старый принцип конструкции , так как даже небольшие встроенные системы имеют достаточно мест как для традиционных объемных корневых файлов и все /usr на одном volume.³ Red Hat Enterprise Linux, Solaris и Cygwin SYMLINK /bin к /usr/bin и /lib к /usr/lib так что нет больше никакой разницы между этими каталогами.
. / local / . очевидно обозначает локальный компьютер .
Да. Это относится к тому факту, что файлы в, /usr/local как предполагается, являются специфическими для этой единственной системы. Файлы, которые в любом случае являются общими, должны находиться в другом месте.
Это также имеет корни в том, как системы Unix обычно использовались десятилетия назад, когда все это было стандартизировано. Опять же, жесткие диски того времени были громоздкими, действительно дорогими и хранили мало по сегодняшним стандартам. Чтобы сэкономить деньги и пространство на дисках, компьютерная лаборатория, полная коробок Unix, часто делится большей частью /usr через NFS или каким-либо другим сетевым протоколом обмена файлами, поэтому у каждого ящика не должно быть своей собственной избыточной копии. Файлы, относящиеся к одному коробка будет идти под /usr/local , который будет отдельный объем от /usr .
Именно из-за этого исторического наследия большинство сторонних программ для Unix по умолчанию /usr/local устанавливаются вручную. Большая часть такого программного обеспечения позволит вам установить пакет где-нибудь еще, но, не делая выбора, вы получите безопасное значение по умолчанию, которое не мешает другим распространенным местам установки с более конкретными целями.
Есть веские причины для установки программного обеспечения в другом месте. Команда компании Apple MacOS делает это , когда они строят, скажем, bash из исходного кода GNU Bash . Они используют / в качестве префикса установки, переопределяя /usr/local значение по умолчанию, так что Bash заканчивается в /bin .
Другой пример — способ, которым старые системы Linux /usr/X11R6 отделяли свое программное обеспечение с графическим интерфейсом , чтобы отделить его от традиционной командной строки и curses программного обеспечения на основе. Это было сделано просто путем переопределения /usr/local префикса по умолчанию с помощью /usr/X11R6 .⁵
Это сокращение от «двоичный», что в данном контексте означает «файл, который не является простым текстом». Большинство таких файлов являются исполняемыми файлами в Unix-боксе, поэтому эти два термина стали синонимами в некоторых кругах. («Пожалуйста, создайте мне двоичный файл для RHEL 7, Фред».)
Текстовые файлы на коробке Unix живут в другом месте: /etc , /usr/include , /usr/share и т.д.
Давным-давно, даже сценарии оболочки, представляющие собой простые текстовые файлы, не содержались в bin каталогах, но эта строка также размылась. Сегодня bin каталоги обычно содержат любой исполняемый файл, будь то «бинарный» или нет.
Сноски и отступления :
Примитивный характер инструментов управления пользователями до SVR4 означал, что HOME=/usr/$NAME схема была просто задокументирована как соглашение, а не применена программными инструментами по умолчанию.
Вы можете увидеть это на странице 4-8 «Руководства системного администратора AT & T Unix System V Release 3.2 : здесь вы видите AT & T, рекомендующую старую /usr/$NAME схему в последней основной версии Unix до выхода SVR4.
В старых системах Unix было довольно распространено, когда системные администраторы выбирали другую схему, которая имела для них больше смысла. Люди были людьми, это означало, что было изобретено много разных схем.
Одна схема, с которой я столкнулся прежде, чем /home/$NAME стала стандартом, была /u/$NAME .
Еще одна система , которую я использовал в начале 1990 — х годов было очень много пользователей , что они не могут поместиться все домашние каталоги на одном физическом томе, поэтому они использовали схему , как /u1/$NAME , /u2/$NAME и так далее, как я помню. На каком диске оказался ваш домашний каталог, было просто вопросом, на каком из них было место на момент создания вашей учетной записи.
Вы можете загрузить MacOS в однопользовательском режиме, удерживая его Cmd-S во время загрузки. Отпустите, как только экран станет черным, и вы увидите светло-серый текст. Это похоже на работу под терминалом, но он занимает весь экран, потому что графический интерфейс еще не запущен.
Будь осторожен, ты бежишь как root .
Введите «exit» в однопользовательском корневом запросе, чтобы выйти из однопользовательского режима и продолжить загрузку в многопользовательском режиме графического интерфейса.
Unixy операционки , которые все еще появляются , чтобы сохранить важные однопользовательский режим файлов из , /usr не может, на самом деле, сделать это в эти дни. Однажды я сделал загрузочную коробку FreeBSD 9 недоступной, перейдя /usr на том ZFS. Я забыл, что возможности ZFS-on-root не были доступны до FreeBSD 10, создав Catch 22 : ОС требовались файлы /usr для монтирования /usr !
Это было достаточно плохо, но если бы FreeBSD 9 по-прежнему не использовала однопользовательскую загрузку /usr , я мог бы это исправить. Поскольку он не загружается даже в однопользовательском режиме, /usr будучи несмонтируемым, очевидно, что традиция каким-то образом была нарушена. Мне пришлось загрузиться с аварийного компакт-диска, чтобы снова восстановить систему.
Это также то, где мы получаем /usr/share : он разделяет файлы, которые могут быть общими даже для блоков Unix с разными типами процессоров. Как правило, текстовые файлы: справочные страницы, словарь и т. Д.
«X11R6» относится к версии системы X Window, лежащей в основе графического интерфейса Linux, в то время, когда это соглашение было распространено. Системы Linux обычно перестали выделять программное обеспечение с графическим интерфейсом примерно во время замены X11R6 на X.Org .
Оригинальные системы Unix сохранили свои основные сценарии оболочки /etc , чтобы избежать смешения с истинными двоичными файлами в /bin .
Источник
/ usr / bin vs / usr / local / bin в Linux
Почему в Linux так много мест для размещения двоичного файла? Есть как минимум эти пять:
И на моем офисном ящике у меня нет разрешений на запись для некоторых из них.
Какой тип двоичного файла входит в какой из этих bin с?
/bin/ для личных вещей.
/bin (и /sbin ) предназначались для программ, которые должны были находиться в небольшом / разделе перед /usr монтированием больших и т. д. разделов. В наши дни он в основном служит стандартным местом для таких ключевых программ, как /bin/sh , хотя первоначальное намерение все еще может иметь значение, например, для установки на небольшие встроенные устройства.
/sbin в отличие от /bin программ управления системой (обычно не используемых обычными пользователями), необходимых перед /usr монтированием.
/usr/bin предназначен для обычных пользовательских программ, управляемых распространением.
Существует /usr/sbin с тем же отношением, /usr/bin что /sbin и к /bin .
/usr/local/bin предназначен для обычных пользовательских программ, не управляемых менеджером пакетов распространения, например, локально скомпилированных пакетов. Вам не следует устанавливать их, /usr/bin потому что будущие обновления дистрибутива могут изменить или удалить их без предупреждения.
/usr/local/sbin , Как вы можете догадаться , на данный момент, является , /usr/local/bin как /usr/sbin к /usr/bin .
Кроме того, есть и /opt монолитные нераспространяемые пакеты, хотя до того, как они были должным образом интегрированы, различные дистрибутивы помещали туда Gnome и KDE. Как правило, вы должны зарезервировать его для больших пакетов с плохим поведением, таких как Oracle.
/bin и добавьте этот каталог в вашу PATH как пользователь . Спасибо за примечание, я удалил свой серьезно устаревший комментарий.
Я рекомендую взглянуть на справочную страницу по иерархии файловой системы:
Который также доступен онлайн, например: http://linux.die.net/man/7/hier
Запись Стандартной иерархии файловой системы в Википедии помогла мне ответить на тот же вопрос, когда он у меня был, плюс у него очень пояснительная таблица.
Выдержка из этой страницы 1 :
В sbin директории содержит программы , которые обычно только систему управления. Программы для постоянных пользователей никогда не должны заходить в них.
Во время запуска требуется несколько программ, которые заканчиваются на /bin/ или /sbin/ . Они должны быть доступны до монтирования файловых систем. Такие вещи, как mount и fsck которые необходимы для проверки и монтирования файловых систем, должны быть там.
Большинство упакованных программ заканчиваются в /usr/bin/ и /usr/sbin/ . Они могут быть в файловой системе, отличной от корневой файловой системы. В некоторых случаях они могут находиться на сетевом диске.
Локальные программы и скрипты принадлежат /usr/local/bin/ а /usr/local/sbin/ . Это идентифицирует их как явно нестандартные и, возможно, доступные только на сайте.
Для дальнейшего объяснения попробуйте man hier выполнить команду, которая должна предоставить описание рекомендуемой иерархии файловой системы для вашего дистрибутива. Вы также можете прочитать об иерархии файловой системы в Википедии.
В 1970-х годах UNIX все официальные исполняемые файлы располагались /bin и /usr/bin находились под домашними каталогами пользователей (например /usr/dmr ), которые были доступны любому пользователю для хранения собственных двоичных файлов, которые могли бы также представлять интерес для других.
Результатом этого открытия /usr/bin стало хранилище недокументированного программного обеспечения, поэтому он Stephen Bourne написал cron script файл, который каждую ночь проверял наличие новых двоичных файлов и удалял все двоичные файлы, у которых не было документации или которые были обновлены без обновления их документации.
В конце 1970-х /usr/bin был интегрирован в базовый дистрибутив ОС, и люди начали использовать его /usr/local/bin с целью предыдущего открытия /usr/bin .
Через некоторое время системные администраторы использовали /usr/local/bin для хранения non-local программного обеспечения, которое было импортировано из сети (например, USENET), и поскольку компании UNIX не хотели повторять ту же ошибку, что и /usr/bin снова, в 1987 году была конференция по иерархии файловой системы, на которой все компании UNIX согласились сдаться /usr/local/bin и использовать /opt/ /bin вместо этого.
К сожалению, дистрибутивы Linux не последовали этому решению .
Источник
