Soyons clairs avec tous les dossiers bin et sbin (à partir de la norme de hiérarchie du système de fichiers):

• /bin est pour les binaires au niveau du système
• /sbin est destiné aux autres fichiers binaires au niveau du système, principalement pour le chargeur de démarrage et les administrateurs système
• /usr/bin est pour les binaires non essentiels
• /usr/sbin- c'est là que le désordre commence - pas d'outils essentiels pour les administrateurs système? Qu'est-ce que ça veut dire? Pour des expériences?
• /usr/local/bin - aucun mot sur ce dossier
• /usr/local/sbin- programmes d'administration système installés localement. Encore? Et alors /usr/sbin?

La question est donc: pourquoi il y a tant de répertoires et quelles sont les significations de /usr/sbin, /usr/local/sbinet /usr/local/bin?

De nombreux programmes sont distribués via des archives et nous devons les construire à partir du code source. Habituellement, ils ont un makefile, donc c'est assez facile. Ce processus implique la création de fichiers dans usr / local / lib, usr / local / bin ... usr / local / peu importe sans créer de dossiers spécifiques pour un programme donné.

Pourquoi en est-il ainsi?

Je pense que ce n'est pas juste parce que si nous devons supprimer le programme, nous devons supprimer manuellement tous ses fichiers si le créateur du programme ne s'en est pas occupé.

1. Structure du répertoire

Cela devrait être traité dans la norme de hiérarchie du système de fichiers ( 2.3 PDF )

/ bin / Essential binaires de commande qui doivent être disponibles en mode mono-utilisateur;
            pour tous les utilisateurs, par exemple, cat, ls, cp

/ sbin / Binaires système essentiels, par exemple, init, ip, mount.

/ usr / bin / Binaires de commande non essentiels (non nécessaires en mode mono-utilisateur); 
            pour tous les utilisateurs

/ usr / sbin / Binaires système non essentiels, par exemple des démons pour divers services réseau.

/ usr / local / Hiérarchie tertiaire pour les données locales, spécifiques à cet hôte. 
            A généralement d'autres sous-répertoires, par exemple, bin /, lib /, share /

2. Installation

J'utilise un gestionnaire de paquets dans la mesure du possible (par exemple, yum ou apt-get). Cela est possible pour un très grand nombre d'applications, dans certains cas, vous devrez peut-être ajouter un référentiel. Mon deuxième choix serait des packages de niveau inférieur tels que les RPM et la compilation à partir de la source serait mon dernier recours (mais certaines personnes préfèrent cela)

Certains gestionnaires de packages peuvent installer à partir de RPM (par exemple yum install oddity.rpm)

Si vous compilez à partir des sources, ce n'est probablement pas une étape énorme pour créer votre propre package afin que l'installateur du système sache ce que vous avez fait.

Ensuite, votre problème se réduit par exemple à yum remove packagename

L'alternative est de conserver une bonne documentation sur toutes les activités sysadmin entreprises (je garde quand même un journal dans un fichier texte)

Les trucs dans tous les répertoires * / sbin ont tendance à n'être utiles qu'aux administrateurs système. Vous pouvez les garder hors de votre CHEMIN si vous êtes un utilisateur normal.

Les différents répertoires n'ont pas beaucoup de sens si vous avez une seule machine Unix sur un seul disque, mais ont plus de sens si vous avez un gros système et des partitions différentes. N'oubliez pas que beaucoup de ces habitudes ont été prises dans les années 80 et 90, lorsque les systèmes étaient un peu différents.

/sbina tendance à être très petit. Ce sont des utilitaires dont vous avez besoin lorsque vous êtes vraiment arrosé. Vous mettriez cela sur une partition racine minimale avec / root et / lib. Les éléments dans / sbin étaient tous liés statiquement, car si votre partition / usr est reliée, toutes les applications liées dynamiquement sont inutiles. fsck est ici et lié statiquement. Si vous avez une dépendance sur / usr, vous ne pouvez évidemment pas fsck / usr /. Bien sûr, si la partition racine est arrosée, vous êtes très foutu. C'est pourquoi il s'agit d'une si petite partition - réduisez les chances d'un bloc de disque défectueux en utilisant très peu de blocs ici.

/usr/sbinles binaires sont des outils sysadmin généraux où vous pouvez au moins passer en mode mono-utilisateur et monter tous vos volumes. Ils peuvent être liés dynamiquement.

Les partitions séparées pour / sbin (enfin, / sbin sur / partition) et / usr ont également plus de sens lorsque vous vous souvenez que la sauvegarde était très coûteuse à la fois en temps et en bande. S'ils se trouvaient sur des partitions distinctes, vous pouvez les planifier différemment.

/usr/localpeut être un système de fichiers réseau. Ainsi, les outils sysadmin écrits localement qui peuvent être partagés sur de nombreuses machines vont parfois dans / usr / local / sbin. Évidemment, aucun utilitaire de réparation de réseau ne peut y aller.

Encore une fois, beaucoup de choses avaient plus de sens sur les grandes machines dans un environnement en réseau sur des machines gérées à plusieurs volumes, moins avec une machine Linux sur une seule partition racine.

Vous devriez vraiment que votre deuxième question soit une question distincte ici sur Superutilisateur. Ce n'est pas lié au premier.

Oui, avoir des fichiers partout est nul. C'est pourquoi il existe de nombreuses solutions d'emballage. RedHat a créé un RPM qui est utilisé partout. Solaris avait son format de package. HP / UX avait le leur, et il existe des formats apt et de nombreux autres packages. Gardez les choses aux bons endroits (/ usr / bin, / usr / lib) selon le cas, mais permettez l'ajout et la suppression faciles.

Pour la source, il existait auparavant des outils qui vous permettraient de configurer et d'installer dans un sous-répertoire de / usr / local et qui géreraient les liens symboliques vers / usr / local / bin pour vous. Depuis la grande prolifération des outils de package, c'est moins nécessaire, et j'ai oublié leurs noms.

Certaines personnes aiment installer dans / opt / packagename et garder tout ensemble là-bas. Le bon: tout est dans un répertoire et une désinstallation est rm -rf /opt/packagename. Les inconvénients sont d'avoir à ajouter / opt / packagename / bin au PATH de chacun, et le fait que les gens ne placent généralement pas / opt sur une partition séparée, et vous remplissez la partition racine.

Mon interprétation de la signification des répertoires (d'après mon expérience avec Debian GNU Linux) est la suivante:

Première distinction: spour superutilisateur

savant qu'un binrépertoire indique qu'il contient des outils qui ne sont normalement utiles qu'aux administrateurs. Notez que par exemple ifconfigappartient également à cette catégorie et j'aime invoquer en ifconfigtant qu'utilisateur régulier (pour vérifier si j'ai obtenu une adresse IP / connectivité réseau), ce qui rend cette distinction pas aussi difficile qu'il y paraît.

Deuxième distinction: localconcerne les "données locales"

Dans la pratique, la distinction la plus importante ici est que les gestionnaires de packages du système d'exploitation (comme APT) installent les packages dans la /usrstructure normale et ne les /usr/localaffectent pas. Cela permet de placer des packages compilés localement ou des scripts internes à l'entreprise fournis par l'administrateur système /usr/localoù ils n'interféreront jamais avec les fichiers correctement packagés.

Il est discutable de savoir s'il /usr/localdoit remplacer les fichiers existants de la /usrstructure normale , voir Est-il dangereux d'avoir / usr / local / bin devant / usr / bin dans son PATH? pour plus de détails à ce sujet.

Troisième distinction: le niveau supérieur /binet les /sbinrépertoires.

Sur Debian, il existe en fait un soi-disant UsrMerge . Il y avait la différence /binet /sbinétaient disponibles dans le processus de démarrage plus tôt (pensez à /usrêtre sur un périphérique réseau ou autre partition, RAID , etc.), mais nowdays quelques systèmes Linux boot et sans ce /usrqui est la raison pour laquelle je considère la distinction entre top- niveau et les /usrrépertoires seront largement d'intérêt historique pour Linux.

Enfin: les mérites et les problèmes de la "diffusion" des fichiers.

Il n'y a vraiment pas de "vraie" réponse à cela. Les avantages du système de fichiers dispersés de Linux sont les suivants:

• Tous les binaires résident dans quelques répertoires. Cela signifie que vous pouvez appeler tous les programmes à partir du shell. Comparez Windows, où il faut toujours éditer la %PATH%variable d'environnement pour ajouter n'importe quel programme d'intérêt. J'ai vu des environnements à très long chemin sur Windows.

• Toutes les bibliothèques résident dans un endroit central. Cela signifie qu'ils n'ont pas besoin d'être installés deux fois lorsqu'ils sont utilisés par plusieurs applications.

• Comme Linux est conçu pour que la plupart des fichiers système soient suivis par un gestionnaire de paquets de toute façon, il n'est pas nécessaire de garder une vue d'ensemble des fichiers du point de vue de l'utilisateur.

• En raison de la normalisation FHS, la documentation réside également dans des endroits centraux permettant des systèmes comme man, infoet de soutien fichiers README au travail comme prévu.

• Il est plus facile de compter sur un programme installé dans un endroit fixe. Tout le monde écrit #!/bin/sh -eou similaire au début des scripts et ça fonctionne . Considérons un système où le shell irait dans un répertoire différent: comment savoir quel nom il prendra? Si vous êtes intéressé, vérifiez les différentes façons d'installer Perl ou LaTeX sur Windows pour voir à quel point cela peut devenir compliqué ...

Les inconvénients que j'ai constatés jusqu'à présent sont les suivants:

• Normalement, il est plus difficile d'exécuter des applications "de manière portative" au sens d '"applications portables pour Windows". Sous Linux, il n'est pas aussi facile de simplement copier le programme sur un autre ordinateur ... il faut avoir le package (qui nécessite des autorisations root) ou gérer LD_LIBRARY_PATHpour pointer les applications vers différents chemins de recherche pour les bibliothèques requises.

• L'installation de plusieurs versions du même programme doit être prise en charge de manière explicite alors que sur les systèmes avec "un répertoire par programme", c'est souvent moins un problème.

• La gestion des fichiers sans gestionnaire de packages est sujette aux erreurs (comme déjà mentionné).

Pour répondre à votre deuxième question:
Habituellement, les programmes sont distribués avec un soi-disant gestionnaire de packages . Un gestionnaire de packages récupère généralement les packages binaires (logiciels compilés pour une certaine plateforme) et les jette dans les répertoires (certains téléchargent le code source, le compilent sur votre machine et l'installent). Ainsi, le gestionnaire de packages sait où résident les fichiers appartenant à certains "programmes" (packages), et lorsque vous souhaitez supprimer le package, le gestionnaire de packages se charge de tout nettoyer.
Même lorsque vous compilez vous-même le code source avec

make

et installez-le avec

make install

vous pouvez généralement faire

make uninstall

qui supprime les fichiers du système de fichiers.