Une autre opinion sur la différence entre bin, sbin, usr/bin, usr/sbin

Récemment, j'ai découvert cet article : Différence entre bin, sbin, usr/bin, usr/sbin. J'aimerais partager mon point de vue sur la norme.

/bin

Il contient des commandes qui peuvent être utilisées à la fois par l'administrateur système et par les utilisateurs, mais qui sont nécessaires lorsqu'aucun autre système de fichiers n'est monté (par exemple, en mode monoposte). Il peut également contenir des commandes qui sont utilisées indirectement par des scripts.

On s'attend à la présence des commandes suivantes :

cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo, faux, nom d'hôte, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true, umount, uname.

On peut créer des liens symboliques vers /usr, mais bien que de nos jours avec systemd, /usr ne soit plus rencontré sur un appareil séparé, il peut encore apparaître dans un système embarqué, un feu tricolore, un moulin à café ou un PDP-11 gérant un appareil crucial dans un laboratoire de l'Académie des Sciences.

/sbin

Les utilitaires utilisés pour l'administration système (et d'autres commandes réservées à root), /sbin contient des fichiers binaires nécessaires au démarrage, à la récupération et/ou à la restauration du système en plus des fichiers binaires dans /bin. Les programmes exécutés après le montage de /usr (lorsqu'il n'y a pas de problème) se trouvent généralement dans /usr/sbin. Les programmes installés localement pour l'administration système doivent être placés dans /usr/local/sbin.

On s'attend à :

fastboot, fasthalt, fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update.

Une des manières de protéger le système des utilisateurs malintentionnés est d'interdire l'exécution de ces utilitaires à tout le monde en définissant l'attribut x.
De plus, remplacer /bin et /sbin par des copies provenant d'une archive (identique pour tous les systèmes de type) est un moyen rapide de réparer les systèmes sans gestionnaire de paquets.

/usr/bin

C'est très simple. Des commandes identiques pour tous les serveurs/moulins à café de l'entreprise. Et /usr peut être déployé de manière identique pour différents OS (pour /bin et /sbin, cela ne fonctionne généralement pas), ce sont des programmes indépendants de l'architecture. Cela peut contenir des liens vers des interprètes perl ou python, qui se trouvent dans /opt ou ailleurs sur le réseau.

/usr/sbin

C'est la même chose que /usr/bin, mais uniquement pour une utilisation par les administrateurs.

/usr/local/bin и /usr/local/sbin

Une des localisations les plus importantes. Contrairement aux autres, /usr ne peut pas être identique pour toute l'organisation. On y trouve des programmes dépendants du système d'exploitation, dépendants du matériel et simplement des programmes qui ne sont pas nécessaires sur tous les appareils. Lors de la synchronisation de /usr sur les machines, /usr/local doit être exclu.

/home/$USER/bin

Ici, le cas est similaire à /usr/local, mais il contient des programmes spécifiques à chaque utilisateur. Ils peuvent être transférés (ou synchronisés) sur une autre machine lors du déménagement de l'utilisateur. Ce qui ne peut pas être transféré se trouve dans /home/$USER/.local/bin. Il est possible d'utiliser local sans le point. /home/$USER/sbin est absent pour des raisons évidentes.

Je serai heureux de recevoir des corrections et des compléments.

Source : habr.com