/bin
Содержит команды, которые могут использоваться как системным администратором, так и пользователями, но которые необходимы, когда не смонтированы никакие другие файловые системы (например, в однопользовательском режиме). Он также может содержать команды, которые косвенно используются скриптами.
Там ожидается присутствие таких команд:
cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, false, hostname, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true, umount, uname.
Можно сделать симлинки на /usr, но хотя во времена systemd /usr на отдельном устройстве не встречается, его еще можно встретить на встраиваемой системе, светофоре, кофемолке
/sbin
Утилиты, используемые для системного администрирования (и другие команды только для 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 по понятным соображениям отсутствует.
Буду рад исправлениям и дополнениям.
Комментарии (30)
amarao
31.07.2019 16:22+4Забыли про существование пакетных менеджеров. /usr/bin и /bin — в их ведомстве, /usr/local — целиком на откупе локальной машины и всякой порнографии в стиле
make install.
Деление на /bin и /usr/bin давно забыло и является артефактом прошлого, в одной категории с шаббатом и крестными ходами. Ничем, кроме религиозных предпочтений и исторических причин, их объяснить нельзя.
dok2d
31.07.2019 17:26Ошибаетесь. Как в пакете расположат, так бинарники и развернутся.
Хоть в /usr/local/bin, хоть в /opt/mssql-tools/bin, хоть в /usr/local/gamesamarao
31.07.2019 17:50Если вы положите в deb что-то в /usr/local/bin, то, технически, это работать будет, но будет нарушать debian policy: https://www.debian.org/doc/debian-policy/ch-opersys.html
9.1.2. Site-specific programs
As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts.
dok2d
31.07.2019 18:00Так точно. Извиняюсь. Погорячился.
У меня там сорцовые бинари лежат, не сразу вспомнил.
mwambanatanga
31.07.2019 16:38+3Присказка:
--Отклонялись ли вы когда-либо от генеральной линии Партии?
--Да, отклонялся… но только вместе с генеральной линией Партии!
— Поскольку в статье сказано, что это «взгляд» на стандарт, можно сделать вывод, что он отличается от генераль… от общепринятого понимания FSHS. И действительно, при прочтении каждого пункта возникает под сознательный протест («а в стандарте же не совсем так»). Так вот, статья очень бы выиграла, если бы в ней авторское толкование шло параллельно букве стандарта, с указанием преимуществ авторского варианта. Ибо при прочтении я уже пару раз лез в стандарт и находил расхождения, а вот преимуществ так и не нашёл.
dvrpd
31.07.2019 17:23+1В том же арче /bin, /sbin и /usr/sbin давным-давно являются симлинками на /usr/bin. /lib64, /lib и /usr/lib64 тоже ссылаются на /usr/lib. Хотя логичнее было бы избавиться от самого /usr, делая его симлинком на корень.
math_coder
31.07.2019 19:04Хотя логичнее было бы избавиться от самого /usr, делая его симлинком на корень.
Если прямо от самого — то нельзя, так как там ещё куча всего вроде /usr/share и той же /usr/local. В корне такого нет.
Fedorkov
31.07.2019 20:11Ещё можно использовать
$HOME/bin, чтобы на скорую руку поправить отвалившийся косяк вроде LD_LIBRARY_PATH. У меня там лежит файл monodevelopвот с таким содержимым,#!/bin/bash # Fix the "cannot connect to debugger" bug. # http://superuser.com/questions/669444/monodevelop-cannot-connect-to-debugger#comment1625964_744763 unset KDE_SESSION_VERSION # Allow remote debugging export MONODEVELOP_SDB_TEST=1 #exec /usr/bin/monodevelop "$@" flatpak run --command=monodevelop --file-forwarding com.xamarin.MonoDevelop @@ "$@" @@slonpts
31.07.2019 20:39Один из способов защиты системы от шаловливых рук юзеров — это запрет запуска этих утилит кому-попало, утсановкой атрибута x.
Даже если забыть про устаревание /sbin и прочего, то защита не очень оказывается — можно файл к себе скопировать. А если не получится — то на дискетке принести / из исходников собрать.DerRotBaron
01.08.2019 11:51По-хорошему можно все доступные "простым смертным" пути монтировать с noexec, правда это существенно ограничивает возможности использования системы. Тем более почти весь /sbin и так не работает без нулевого UID.
К тому же 750 на утилитах в /sbin (так делают, например,
OpenSUSE) ломает умные дополнения умных шеллов, что весьма неудобно.math_coder
01.08.2019 17:05почти весь /sbin и так не работает без нулевого UID
Это очень важное "почти". В /sbin есть команды, которым достаточно, чтобы юзер был в группе operator (что в случае обычного компьютера выполянется для всех "простых смертных").
netch80
31.07.2019 20:56+1Исторически вариантов сильно больше. На солярках долго /usr/xpg4/bin отличался от /usr/bin — те, кому нужно было соответствие стандартам, а не локальным тараканам, ставили /usr/xpg4/bin вперёд.
Сейчас есть /usr/games, отдельно. На FreeBSD был /stand, теперь /rescue.
divanikus
31.07.2019 21:26+2Разница между /bin и /usr/bin в одном «фото»:
$ ls -l / lrwxrwxrwx 1 root root 7 Apr 25 09:57 bin -> usr/bin lrwxrwxrwx 1 root root 7 Apr 25 09:57 lib -> usr/lib lrwxrwxrwx 1 root root 9 Apr 25 09:57 lib32 -> usr/lib32 lrwxrwxrwx 1 root root 9 Apr 25 09:57 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 10 Apr 25 09:57 libx32 -> usr/libx32 lrwxrwxrwx 1 root root 8 Apr 25 09:57 sbin -> usr/sbin
Debian Buster 10.09660
02.08.2019 08:33Не наблюдаю ничего подобного:
cat /etc/os-release
PRETTY_NAME=«Debian GNU/Linux 10 (buster)»
NAME=«Debian GNU/Linux»
VERSION_ID=«10»
VERSION=«10 (buster)»
VERSION_CODENAME=buster
ID=debian
HOME_URL=«www.debian.org»
SUPPORT_URL=«www.debian.org/support»
BUG_REPORT_URL=«bugs.debian.org»
netadm@lb01:~$ ls -l /
total 113
drwxr-xr-x 2 root root 4096 июл 30 04:55 bin
drwxr-xr-x 20 root root 4096 июл 30 04:56 lib
drwxr-xr-x 2 root root 4096 июл 30 04:19 lib64
drwxr-xr-x 2 root root 12288 июл 30 04:55 sbinTonyLorencio
03.08.2019 00:31Скорее всего, ваша система обновлена со stretch. При обновлении с предыдущего релиза /usr merge не происходит
When upgrading to buster, systems are left as they are, although the usrmerge package exists to do the conversion if desired.
benjamen
31.07.2019 22:30-1К слову католог /usr означает unified system resources — что и обуславливает всё что в ней.
danyisill
01.08.2019 03:32На самом деле все исполняемые файлы должны быть доступны из /bin, а $PATH — архаизм. Так сделано, например, в Plan 9 — исполняемые файлы из разных директорий (например /386 + /usr/usrname/bin) динамически смонтированы в /bin при помощи bind
iig
01.08.2019 07:26+1Вместо "должны" нужно писать "могут быть". Системе все равно, в одной директории все файлы или в разных. Человеку — удобнее, когда в разных.
azudem
01.08.2019 04:55+2И это статья для хабра? Грёбаный стыд.
justhabrauser
01.08.2019 08:02+3Тем не менее статья набрала +9 лайков, а автор — кармы +3.
Вот это — гребёный стыд.
С кем поведешься — от того и забеременеешь (tm)
Gurturok
01.08.2019 09:19Хотелось бы поделиться своим взглядом
Очень хорошо что у тебя есть свой взгляд, но в оригинальной статье (и в других источниках, если поискать) четко сказано почему появился /usr и почему в современном мире он не нужен.
Вообще ментейнеры любого дистрибутива могут без вреда для пользователей убрать
дублирующие каталоги в /usr, но то ли они привыкли следовать традициям, то ли лень все пересобирать.9660
02.08.2019 08:39-1/bin, /sbin убрать в /usr?
И получить проблему при ошибке маунта /usr? Так себе идея на мой взгляд.
Boozlachu
01.08.2019 10:32+1www.pathname.com/fhs
Исчерпывающее сведения, что где должно лежать. Стандарт
Oz_Alex
Статья выглядит, как перепечатка первой лекции по Linux, с очепятками и пропущенными запятыми.