1. Structure du répertoire
Cela devrait être couvert dans le Filesystem Hierarchy Standard (2.3 PDF)
/bin/ Essential command binaries that need to be available in single user mode;
for all users, e.g., cat, ls, cp
/sbin/ Essential system binaries, e.g., init, ip, mount.
/usr/bin/ Non-essential command binaries (not needed in single user mode);
for all users
/usr/sbin/ Non-essential system binaries, e.g. daemons for various network-services.
/usr/local/ Tertiary hierarchy for local data, specific to this host.
Typically has further subdirectories, e.g., bin/, lib/, share/
2. Mise en place
J'utilise un gestionnaire de paquets dans la mesure du possible (par exemple, yum ou apt-get). Ceci est possible pour un très grand nombre d'applications, dans quelques cas vous devrez peut-être ajouter un référentiel. Mon deuxième choix serait les packages de niveau inférieur tels que les RPM et la compilation à partir des sources 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 paquet afin que l'installateur du système sache ce que vous avez fait.
Ensuite, votre problème se réduit à par ex. yum remove packagename
L'alternative est de conserver une bonne documentation sur toutes les activités d'administration système entreprises (je tiens de toute façon un journal dans un fichier texte)
Les éléments de tous les répertoires */sbin ont tendance à n'être utiles qu'aux administrateurs système. Vous pouvez les garder hors de votre PATH 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 différentes partitions. 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.
/sbin a tendance à être très petit. Ce sont des utilitaires dont vous avez besoin lorsque vous êtes vraiment arrosé. Vous placeriez ceci sur une partition racine minimale avec /root et /lib. Auparavant, les éléments de /sbin étaient tous liés de manière statique, car si votre partition /usr est hébergée, toutes les applications liées de manière dynamique 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 vraiment foutu. C'est pourquoi il s'agit d'une si petite partition - réduisez les risques d'un bloc de disque défectueux en utilisant très peu de blocs ici.
/usr/sbin les binaires sont des outils généraux d'administration système où vous pouvez au moins passer en mode mono-utilisateur et monter tous vos volumes. Ils sont autorisés à ê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 en temps et en bande. S'ils se trouvaient sur des partitions distinctes, vous pourriez les programmer différemment.
/usr/local peut être un système de fichiers réseau. Ainsi, les outils d'administration système é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 accéder.
Encore une fois, beaucoup de choses avaient plus de sens sur de grosses machines dans un environnement en réseau sur des machines gérées avec plusieurs volumes, moins avec une machine Linux sur une seule partition racine.
Votre deuxième question devrait vraiment être une question distincte ici sur Superuser. C'est sans rapport avec le premier.
Oui, avoir des fichiers partout, c'est nul. C'est pourquoi il existe de nombreuses solutions d'emballage. RedHat a créé RPM qui est utilisé partout. Solaris avait son format de package. HP/UX avait le leur, et il y a apt et de nombreux autres formats de package. Conservez les éléments aux bons endroits (/usr/bin, /usr/lib) selon le cas, mais autorisez l'ajout et la suppression faciles.
Pour la source, il y avait des outils qui vous permettaient de configurer et d'installer dans un sous-répertoire de /usr/local et de gérer 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/nomdupaquet et gardez tout ensemble là-bas. Le bon :tout est dans un répertoire et une désinstallation est rm -rf /opt/packagename . Les inconvénients de cela sont d'avoir à ajouter /opt/packagename/bin au PATH de tout le monde, et le fait que les gens ne mettent généralement pas /opt sur une partition séparée, et vous remplissez la partition racine.