Quelle est la raison d'être du répertoire `/ usr`?

107

Quelle est la raison d'être des "ressources système Unix", ou du /usrrépertoire, comme décrit ici , qui dupliquent de nombreux noms de répertoires sous le répertoire racine /?

Mon but: J'installe Oracle JDK pour la énième fois et j'ai décidé de le mettre sous /home/user. Je lis juste un peu pour voir si c'est une mauvaise idée sur une machine à utilisateur unique.

H2ONaCl
la source
1
Votre répertoire personnel est l’endroit idéal pour installer un logiciel tiers en tant qu’utilisateur non root.
Lekensteyn
10
... la triste réalisation parce que vous pensiez /usrsignifiait un répertoire "utilisateur" caché pendant tant d'années ...
Govind Rai
8
J'ai sérieusement pensé que c'était "utilisateur" tout ce temps. Comme les binaires de l'utilisateur
Tanner Babcock
@TannerBabcock Je pense que c'est. Au moins, je pense que / usr / bin est censé se trouver là où sont installés des fichiers binaires à l’échelle du système qui ne sont pas considérés comme essentiels au système.
David A. French il y a

Réponses:

169

Il y a la version courte et la version longue de votre réponse ...

Version courte:

Comme votre lien déjà dit, /usrest un lieu pour l' ensemble du système , en lecture seule des fichiers. Donc, tous vos logiciels installés y vont. Il ne duplique pas les noms de /sauf /binet /lib, mais, à l'origine, dans un but différent: il /bin, /libne concerne que les fichiers binaires et les bibliothèques nécessaires au démarrage , alors /usr/bin, /usr/libque tous les autres exécutables et bibliothèques le sont. (maintenant soyez un bon garçon et ne posez pas de questions /sbin, c'est la version courte après tout)

De nos jours, la distinction entre "requis pour le démarrage" et non a diminué, car la plupart des distributions modernes, y compris Ubuntu, ne peuvent pas démarrer correctement sans plusieurs fichiers /usr. Et c’est la raison pour laquelle il existe un fort mouvement en faveur de la fusion /usr/binet /bin, donc probablement dans un proche avenir (Ubuntu 12.10 peut-être?) /binSera un lien symbolique vers /usr/bin.

Mais peut-être vous confondez /usret /usr/local? Parce que oui, il y a (et devrait être) beaucoup de noms de répertoires dupliqués. Plus sur cela plus tard ...

Version longue:

Dans les années 70, sous Unix (oui, Unix, bien avant Linux), les disquettes avaient peu d’espace (pas de disque dur, rappelez-vous?) Et, à un moment donné, le nombre et la taille des fichiers binaires du système devenaient trop importants. Un seul disque suffit pour permettre aux développeurs de les répartir sur plusieurs supports afin de leur créer de nouveaux points de montage. /binsystème de fichiers était pleine, ils les nouveaux fichiers binaires installé à ... /usr/bin. Et /usrétait, à cette époque, leur répertoire utilisateur !

Après la scission (presque gênante et souvent racontée sous forme de blague / histoire), ils ont commencé à créer des justifications (et des critères) "artificiels" pour décider de ce qui irait /binet de ce qui irait /usr/bin. La règle informelle était: les choses "essentielles" vont à /bin, "le reste" va à /usr/bin. Même avec /lib. Il n’a pas fallu longtemps pour que cela /usrdevienne encombré de répertoires liés au système, mélangés à des répertoires d’utilisateur. Ainsi /homeest née la tâche de garder tous les répertoires liés à l’utilisateur et de rester /usrpropres pour les "choses" système uniquement.

C'était bien avant que FHS existe. Quand il a été créé, il a adopté (et officialisé) la tradition actuelle et en a conservé le nom /usr, même si, à cette époque, cela n'avait plus rien à voir avec "utilisateur". Alors oui, les noms de fantaisie « U NIX s Ource r de epository » ou « U NIX s ystème r ESSOURCES » sont tous les noms confectionnés, et il est trop tard pour le renommer de toute façon. (mais pas trop tard pour le fusionner /bin)

"Ok, et à propos de quoi /usr/sbin?" , tu demandes. Bon sang, j'espérais que tu avais oublié. Ok ... /usr/sbinest pour les commandes qui ne peuvent (ou n'ont de sens que lorsque) exécutées par l' rootutilisateur, comme mountet fdisk.

"Mais n'est-ce pas presque pareil /bin?" . Oui, bien sûr, mais ...

"Attends, alors pourquoi y en a-t-il /sbinaussi? Ça n'a aucun sens!" . Eh bien, c'est à cause de ... euh .. humm ..

Regardez, un singe à 3 têtes derrière vous!

Ok, espérons-le, vous êtes assez distrait. Passer à autre chose ...

(Si vous pensez que je triche, oui, vous avez raison. Mais il en va de même pour les commandes essentielles "de réponse officielle" qui ne peuvent être exécutées que par root et doivent être disponibles avant même de monter /"). La vérité est que: la ligne est en effet floue et qu'il y a beaucoup de noms hérités qui "restent collés" et qu'il est maintenant très difficile de s'en débarrasser.

Plus sur le cas pour la /usrfusion , de systemddocs:

La justification historique de / bin, / sbin et / lib séparés de / usr ne s'applique plus aujourd'hui. Ils ont été séparés pour avoir sélectionné les outils sur un disque dur plus rapide (ce qui était petit, parce que c’était plus cher) et pour contenir tous les outils nécessaires au montage de la partition / usr plus lente. Aujourd’hui, une initialisation distincte doit déjà être montée par initramfs lors de l’amorçage, ce qui justifie la création d’une unité divisée. En outre, de nombreux outils dans / bin et / sbin dans le statu quo ont déjà perdu la capacité de fonctionner sans / usr pré-monté. Il n'y a plus aucune raison valable pour avoir le système d'exploitation réparti sur plusieurs hiérarchies, il a perdu sa raison d'être.

Et une lecture étonnante sur la /usrscission et sa raison d'être, par Rob Landley:

Comprendre les fichiers bin, sbin, usr / bin, usr / sbin

Aujourd'hui

Actuellement, en ce qui concerne les répertoires d'installation, la meilleure façon de comprendre est de penser de cette façon:

  • /usr - tous les fichiers en lecture seule installés à l’échelle du système et installés par (ou fournis par) le système d’exploitation

  • /usr/local- fichiers en lecture seule installés à l’échelle du système et installés par l’administrateur local (généralement vous). Et c’est pourquoi la plupart des noms de répertoires /usrsont dupliqués ici.

  • /opt- une atrocité destinée à des logiciels autonomes , en lecture seule et à l' échelle du système . C'est un logiciel qui ne divise pas leurs fichiers sur bin, lib, share, includecomme les logiciels bien comportés devrait.

  • ~/.local- la contrepartie par utilisateur de /usr/local, c'est-à-dire: les logiciels installés par (et pour) chaque utilisateur

  • ~/.local/opt - la contrepartie par utilisateur de /opt

Alors, où installer un logiciel?

La liste ci-dessus constitue déjà la moitié de la réponse à votre question sur le JDK Oracle, du moins, elle donne plusieurs indices. La liste de contrôle "Où dois-je installer le logiciel X?" passe par:

  • Est-ce un logiciel de répertoire unique, complètement autonome, comme Eclipse IDE et d'autres applications Java téléchargées, et vous souhaitez qu'il soit disponible pour tous les utilisateurs? Puis installez dans/opt

  • Comme ci-dessus, mais vous ne vous souciez pas des autres utilisateurs et je veux installer pour votre seul utilisateur? Puis installez dans~/.local/opt

  • Ses fichiers répartis sur plusieurs répertoires, comme binet share, comme les logiciels traditionnels compilés et installés avec ./configure && make && sudo make install, devraient être disponibles pour tous les utilisateurs? Puis installez dans/usr/local

  • Comme ci-dessus, mais uniquement pour votre utilisateur? Puis installez dans~/.local

  • Logiciels installés par le système d'exploitation ou via des gestionnaires de packages (tels que Software Center) et, plus important encore, quelles modifications locales pourraient être écrasées lorsque le gestionnaire de mise à jour les met à niveau vers une nouvelle version ? Il va à/usr

Remarques:

  • Ceci explique pourquoi le préfixe d'installation par défaut pour les logiciels compilés est /usr/local, et pourquoi vous devriez le changer en ./configure --prefix=$HOME/.locallors de l'installation du logiciel pour votre propre utilisateur uniquement.

  • Vous avez peut-être remarqué que tous les répertoires ci-dessus sont en lecture seule (sauf, bien sûr, lorsque vous installez / supprimez des logiciels). Les fichiers accessibles en écriture (tels que les fichiers de configuration) sont généralement placés dans /etc(pour les logiciels système) et ~/.config(pour les paramètres par utilisateur). Bien que de nombreux logiciels hérités (et, malheureusement, certains modernes également) utilisent ~/.<software-name>, encombrent votre dossier de départ avec des milliards de répertoires et de fichiers.

  • ~/.localet ~/.configne font pas partie de la spécification FHS. FHS ne traite pas le dossier personnel de l'utilisateur. Il s’agit d’une tentative de XDG, une autre organisation standard axée sur les environnements de bureau (tels que Gnome, KDE et Unity), pour tenter de définir certaines conventions concernant la structure du domicile de l’utilisateur. Tous les logiciels n'y adhèrent pas (par exemple, ce ~/.local/binn'est pas dans la configuration par défaut de l'utilisateur $PATH, alors que ce devrait être logique) , et aucun utilisateur n'est obligé de le suivre, mais les deux bénéficient de nombreux avantages en termes d'interopérabilité.

J'espère que cela aide à clarifier un peu les choses. N'hésitez pas à demander n'importe quoi pour que je puisse améliorer la réponse!

(Et j'espère aussi que les puristes ne me tueront pas pour un langage et une explication aussi informels. C'était intentionnel, et il contient sûrement de nombreuses inexactitudes, mais je pense que c'est un bon moyen de donner à un nouvel arrivant un bref aperçu de l'installation répertoires rationnels)

MestreLion
la source
1
Vous avez résumé la situation de manière très concise et, oui, c'est vrai, la réponse complète est une histoire beaucoup plus longue que la précédente!
papashou
Pourquoi pas? La même logique s'applique: un attaquant peut créer un fichier exécutable sous le répertoire principal ou un sous-répertoire de ce dernier, nommé d'après une commande système.
Ignis le
3
@ignis: si un attaquant a le droit de créer et de modifier des fichiers sous le domicile de l'utilisateur, cet utilisateur est déjà complètement compromis et $PATHn'a aucune pertinence. L'attaquant peut même changer cela via ~/.profile, votre argument est donc sans objet. ~/.local/binest aussi sécurisé (ou non sécurisé, si vous le souhaitez) que ~/bin, pratique courante dans la plupart des distributions. L'idée qu'un utilisateur ne devrait avoir aucun répertoire pour conserver et exécuter des scripts personnels $PATHest absurde.
MestreLion
Ainsi, ~/binest aussi sûr que ~/.profile, et $PATHne me protège pas contre les logiciels malveillants que je gère (qui a l’autorisation d’écrire à mon domicile). Je ne connaissais pas ce fichier, je suis désolé. Merci pour la clarification, désolé pour mon commentaire précédent.
Ignis
Plus son histoire est longue, plus il y a d'amélioration / désordre.
smwikipedia