Another opinion on the difference between bin, sbin, usr / bin, usr / sbin
I recently found this article: The difference between bin, sbin, usr / bin, usr / sbin . I would like to share my opinion on the standard.
Contains commands that can be used by both the system administrator and users, but which are necessary when no other file systems are mounted (for example, in single-user mode). It may also contain commands that are indirectly used by scripts.
The following teams are expected to be there:
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 .
It is possible to make symlinks on / usr, but although it was not found on a separate device during systemd / usr, it can still be found on an embedded system, traffic light, coffee grinderand PDP-11 serving an important device in one of the laboratories of the Academy of Sciences .
Utilities used for system administration (and other root-only commands), / sbin contains the binaries needed to boot, restore, restore, and / or restore the system in addition to the binaries in / bin. Programs executed after / usr is mounted (when there are no problems) are usually placed in / usr / sbin. Locally installed system administration programs should be placed in / usr / local / sbin.
Expected:
fastboot, fasthalt, fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update .
One way to protect the system from the playful hands of users is to prohibit anyone from running these utilities by setting the x attribute.
In addition, replacing / bin and / sbin with a copy from the archive (the same for all systems of the same type) is a quick way to fix systems without a package manager.
Everything is simple here. The same type of team, the same for all servers / coffee grinders company. And / usr itself can be deployed the same for different OS (for / bin and / sbin this usually does not work), these are architecturally independent programs. It may contain links to perl or python interpreters that are in / opt or somewhere else on the network.
Same as / usr / bin, but for use by admins only.
One of the most important locations. Unlike the rest, / usr cannot be the same for the entire organization. Here are OS-dependent, hardware-dependent and just programs that are not needed on all devices. When synchronizing / usr on machines, / usr / local must be excluded.
Here the case is similar to / usr / local, only the programs specific to a specific user lie. You can transfer (or synchronize) to another machine when the user moves. That which cannot be transferred is added to /home/$USER/.local/bin. You can use local without a dot. / home / $ USER / sbin for obvious reasons is missing.
I will be glad to corrections and additions.
/ bin
Contains commands that can be used by both the system administrator and users, but which are necessary when no other file systems are mounted (for example, in single-user mode). It may also contain commands that are indirectly used by scripts.
The following teams are expected to be there:
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 .
It is possible to make symlinks on / usr, but although it was not found on a separate device during systemd / usr, it can still be found on an embedded system, traffic light, coffee grinder
/ sbin
Utilities used for system administration (and other root-only commands), / sbin contains the binaries needed to boot, restore, restore, and / or restore the system in addition to the binaries in / bin. Programs executed after / usr is mounted (when there are no problems) are usually placed in / usr / sbin. Locally installed system administration programs should be placed in / usr / local / sbin.
Expected:
fastboot, fasthalt, fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update .
One way to protect the system from the playful hands of users is to prohibit anyone from running these utilities by setting the x attribute.
In addition, replacing / bin and / sbin with a copy from the archive (the same for all systems of the same type) is a quick way to fix systems without a package manager.
/ usr / bin
Everything is simple here. The same type of team, the same for all servers / coffee grinders company. And / usr itself can be deployed the same for different OS (for / bin and / sbin this usually does not work), these are architecturally independent programs. It may contain links to perl or python interpreters that are in / opt or somewhere else on the network.
/ usr / sbin
Same as / usr / bin, but for use by admins only.
/ usr / local / bin and / usr / local / sbin
One of the most important locations. Unlike the rest, / usr cannot be the same for the entire organization. Here are OS-dependent, hardware-dependent and just programs that are not needed on all devices. When synchronizing / usr on machines, / usr / local must be excluded.
/ home / $ USER / bin
Here the case is similar to / usr / local, only the programs specific to a specific user lie. You can transfer (or synchronize) to another machine when the user moves. That which cannot be transferred is added to /home/$USER/.local/bin. You can use local without a dot. / home / $ USER / sbin for obvious reasons is missing.
I will be glad to corrections and additions.
All Articles