Еще одно мнение о разнице между bin, sbin, usr/bin, usr/sbin

Недавно я обнаружил вот такую статью: Разница между bin, sbin, usr/bin, usr/sbin. Хотелось бы поделиться своим взглядом на стандарт.

/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 на отдельном устройстве не встречается, его еще можно встретить на встраиваемой системе, светофоре, кофемолке и PDP-11 обслуживающем важный прибор в одной из лабораторий Академии Наук.

/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 по понятным соображениям отсутствует.

Буду рад исправлениям и дополнениям.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 31

    +9
    Хотелось бы поделиться своим взглядом на стандарт.
    Так где свой взгляд на стандарт?
    Статья выглядит, как перепечатка первой лекции по Linux, с очепятками и пропущенными запятыми.
      +13

      Забыли про существование пакетных менеджеров. /usr/bin и /bin — в их ведомстве, /usr/local — целиком на откупе локальной машины и всякой порнографии в стиле make install.


      Деление на /bin и /usr/bin давно забыло и является артефактом прошлого, в одной категории с шаббатом и крестными ходами. Ничем, кроме религиозных предпочтений и исторических причин, их объяснить нельзя.

        –2
        Ошибаетесь. Как в пакете расположат, так бинарники и развернутся.
        Хоть в /usr/local/bin, хоть в /opt/mssql-tools/bin, хоть в /usr/local/games
          +1
          только вот QA дистрибутива такое не допустит. почитайте стандарты уже.
            +2

            Если вы положите в 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.

              0
              Так точно. Извиняюсь. Погорячился.
              У меня там сорцовые бинари лежат, не сразу вспомнил.
          +4
          Подскажу:
          man hier
          • UFO just landed and posted this here
              +2
              В том же арче /bin, /sbin и /usr/sbin давным-давно являются симлинками на /usr/bin. /lib64, /lib и /usr/lib64 тоже ссылаются на /usr/lib. Хотя логичнее было бы избавиться от самого /usr, делая его симлинком на корень.
                0
                Вот пример упрощенной иерархии: sta.li/filesystem
                  0
                  Хотя логичнее было бы избавиться от самого /usr, делая его симлинком на корень.

                  Если прямо от самого — то нельзя, так как там ещё куча всего вроде /usr/share и той же /usr/local. В корне такого нет.

                    0
                    Верно, я и имел ввиду перемещение share в корень.
                  +5
                  Оказывается, получить инвайт можно вот так просто, не знал.
                    +1

                    Прочитать man hier (правда не поняв по конца) нынче дорого стоит

                    0
                    Ещё можно использовать $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 @@ "$@" @@
                    который прозрачно запускается вместо /usr/bin/monodevelop. Только для этого путь $HOME/bin должен быть прописан в самом начале $PATH (export PATH="$HOME/bin:$PATH"). В дебианах вроде по умолчанию так.
                      0
                      Один из способов защиты системы от шаловливых рук юзеров — это запрет запуска этих утилит кому-попало, утсановкой атрибута x.

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

                        По-хорошему можно все доступные "простым смертным" пути монтировать с noexec, правда это существенно ограничивает возможности использования системы. Тем более почти весь /sbin и так не работает без нулевого UID.
                        К тому же 750 на утилитах в /sbin (так делают, например,
                        OpenSUSE) ломает умные дополнения умных шеллов, что весьма неудобно.

                          0
                          почти весь /sbin и так не работает без нулевого UID

                          Это очень важное "почти". В /sbin есть команды, которым достаточно, чтобы юзер был в группе operator (что в случае обычного компьютера выполянется для всех "простых смертных").

                        +1
                        Исторически вариантов сильно больше. На солярках долго /usr/xpg4/bin отличался от /usr/bin — те, кому нужно было соответствие стандартам, а не локальным тараканам, ставили /usr/xpg4/bin вперёд.

                        Сейчас есть /usr/games, отдельно. На FreeBSD был /stand, теперь /rescue.

                          +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.0
                            0
                            Не наблюдаю ничего подобного:

                            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 sbin
                              0

                              Скорее всего, ваша система обновлена со stretch. При обновлении с предыдущего релиза /usr merge не происходит


                              When upgrading to buster, systems are left as they are, although the usrmerge package exists to do the conversion if desired.
                            –2
                            К слову католог /usr означает unified system resources — что и обуславливает всё что в ней.
                              0
                              На самом деле все исполняемые файлы должны быть доступны из /bin, а $PATH — архаизм. Так сделано, например, в Plan 9 — исполняемые файлы из разных директорий (например /386 + /usr/usrname/bin) динамически смонтированы в /bin при помощи bind
                                +1

                                Вместо "должны" нужно писать "могут быть". Системе все равно, в одной директории все файлы или в разных. Человеку — удобнее, когда в разных.

                                +2

                                И это статья для хабра? Грёбаный стыд.

                                  +3
                                  Тем не менее статья набрала +9 лайков, а автор — кармы +3.
                                  Вот это — гребёный стыд.
                                  С кем поведешься — от того и забеременеешь (tm)
                                  0
                                  Хотелось бы поделиться своим взглядом

                                  Очень хорошо что у тебя есть свой взгляд, но в оригинальной статье (и в других источниках, если поискать) четко сказано почему появился /usr и почему в современном мире он не нужен.

                                  Вообще ментейнеры любого дистрибутива могут без вреда для пользователей убрать
                                  дублирующие каталоги в /usr, но то ли они привыкли следовать традициям, то ли лень все пересобирать.
                                    –1
                                    /bin, /sbin убрать в /usr?
                                    И получить проблему при ошибке маунта /usr? Так себе идея на мой взгляд.
                                      0
                                      Есть такая проблема, у нас регулярно вылазила на FreeBSD. Там стиль по умолчанию как раз предполагал (а может, и сейчас) отделение /usr в отдельный раздел, и если он не монтировался (например, из-за переименований wd0/ad0, ad4/ata1, etc.), то надо было дорабатывать руками.

                                      Лечили — или терпели проблемы при перемещении (это обычно таки один раз) и правили fstab вручную, или объединяли /usr с / (но тогда надо было подумать, как выносить /usr/local).

                                      Тогда я тосковал по наличию LVM у некоторых соседей.

                                      На Linux сейчас такие проблемы тоже возможны, но лечатся скорее другими средствами: busybox с набором штатных утилит в initrd, UUIDʼы в fstab…
                                    +1
                                    www.pathname.com/fhs

                                    Исчерпывающее сведения, что где должно лежать. Стандарт

                                    Only users with full accounts can post comments. Log in, please.