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


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

Mon but: j'installe Oracle JDK pour la énième fois et décide cette fois de le mettre sous /home/user et je lis un peu pour voir si c'est une mauvaise idée sur une machine mono-utilisateur.


88
2018-05-02 16:46


origine


Votre répertoire personnel est l'endroit idéal pour installer des logiciels tiers en tant que non-root. - Lekensteyn
... la triste réalisation parce que tu pensais /usr signifiait un répertoire "utilisateur" caché pendant tant d'années ... - Govind Rai
J'ai sérieusement pensé que c'était "utilisateur" tout ce temps. Comme les binaires utilisateur - Tanner Babcock


Réponses:


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

Version courte:

Comme votre lien l'a déjà dit, /usr est un lieu pour à l'échelle du système, lecture seulement des dossiers. Donc, tous vos logiciels installés y vont. Il ne duplique aucun nom de / sauf /bin et /lib, mais, à l'origine, avec un objectif différent: /bin, /lib est seulement pour les binaires et les bibliothèques requis pour démarrer, tandis que /usr/bin, /usr/lib est pour tous les autres exécutables et bibliothèques. (maintenant soyez un bon garçon et ne demandez pas /sbin, c'est la version courte après tout)

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

Mais peut-être que vous êtes déroutant /usr et /usr/local? Parce que oui, il y a (et devrait être) un lot des 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 HD, rappelez-vous?), Et à un moment donné, les binaires du système adapter un seul disque, et les développeurs ont dû les séparer sur plusieurs médias et créer ainsi de nouveaux points de montage pour eux. /bin le système de fichiers était plein, ils ont donc installé les nouveaux fichiers binaires sur ... /usr/bin. Et /usr était, à cette époque, leur ... utilisateur annuaire!

Après la séparation (presque embarrassante et souvent racontée comme une blague / histoire), ils ont commencé à créer des justifications (et critères) «artificiels» pour décider de ce qui irait à /bin et ce qui irait à /usr/bin. La règle informelle était la suivante: les choses "essentielles" vont à /bin, "le reste" va à /usr/bin. Même avec /lib. Il n'était pas long avant /usr est devenu encombré de répertoires liés au système, mélangés avec des répertoires d'utilisateurs. Ainsi /home est né, de garder tous les répertoires liés à l'utilisateur et de garder /usr nettoyer pour le système "stuff" seulement.

C'était long avant que FHS existe. Quand il a été créé, il a embrassé (et formalisé) la tradition actuelle et gardé le nom /usr, même si à cette époque, cela n'avait plus rien à voir avec "l'utilisateur". Alors oui, les noms de fantaisie "U RIEN s ource r epositoire "ou"U RIEN s ystem r esources "sont tous des noms composés, et il est trop tard pour le renommer de toute façon. (mais pas trop tard pour fusionner /binà elle)

"Ok, qu'en est-il /usr/sbin? ", tu demandes. Bon sang, j'espérais que tu avais oublié. D'accord... /usr/sbin est pour les commandes qui ne peuvent être (ou ne sont significatives que quand) exécutées par le root utilisateur, comme mount et fdisk.

"Mais n'est-ce pas la même chose que /bin? ". Oui, bien sûr, mais ...

"Attendez, alors pourquoi il y a un /sbin aussi? Ça n'a aucun sens! ". Eh bien, c'est à cause de ... euh ... humm ..

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

Ok, j'espère que vous avez été assez distrait. Aller de l'avant ...

(si vous pensez que je triche, oui, vous avez raison. Mais les commandes essentielles "de réponse" officielles 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 fait floue, et qu’il ya beaucoup de noms hérités qui sont simplement" bloqués "et qu’il est maintenant très difficile de les éliminer.

Plus sur le Cas pour le /usr fusionner, de systemd docs:

La justification historique pour un / bin, / sbin et / lib distinct de / usr ne s'applique plus aujourd'hui. Ils ont été séparés pour avoir sélectionné des outils sur un disque dur plus rapide (ce qui était petit, car cela coûtait plus cher) et contenir tous les outils nécessaires pour monter la partition plus lente / usr. Aujourd'hui, une partition séparée / usr doit déjà être montée par les initramfs lors du démarrage initial, ce qui justifie la résolution des problèmes. En outre, de nombreux outils dans / bin et / sbin dans le statu quo ont déjà perdu la capacité d’exécuter sans pré-monté / usr. Il n'y a plus de raison valable pour que le système d'exploitation soit réparti sur plusieurs hiérarchies, il a perdu son objectif.

Et une lecture incroyable sur le /usr split et sa raison d'être, par Rob Landley:

Comprendre le bin, sbin, usr / bin, le partage usr / sbin

Aujourd'hui

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

  • /usr - tous les fichiers système en lecture seule installés par (ou fournis par) le système d'exploitation

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

  • /opt - une atrocité destinée à l'ensemble du système, en lecture seule et autonome Logiciel. C'est-à-dire un logiciel qui ne partage pas ses fichiers bin, lib, share, include comme le logiciel bien comporté devrait.

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

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

Alors, où installer le logiciel?

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

  • S'agit-il d'un logiciel de répertoire unique entièrement 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

  • Même chose que ci-dessus, mais vous ne vous souciez pas des autres utilisateurs et je veux installer uniquement pour votre utilisateur? Puis installez dans ~/.local/opt

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

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

  • Logiciels installés par le système d’exploitation ou par l’intermédiaire de gestionnaires de packages (tels que Software Center), et surtout, toute modification locale pourrait être écrasée lorsque le gestionnaire de mise à jour le met à niveau vers une nouvelle version? Il va à /usr

Remarques:

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

  • Vous avez peut-être remarqué que tout les répertoires ci-dessus sont lecture seulement (sauf, bien sûr, lorsque vous installez / supprimez un logiciel). Les fichiers accessibles en écriture (comme les fichiers de configuration) vont généralement à /etc (pour les logiciels à l'échelle du système) et ~/.config (pour les paramètres par utilisateur). Bien que de nombreux logiciels hérités (et, malheureusement, certains modernes) utilisent ~/.<software-name>, encombrant votre dossier personnel avec des milliards de répertoires et de fichiers.

  • ~/.local et ~/.config ne font pas partie de la spécification FHS. FHS ne traite pas du dossier personnel de l'utilisateur. Il s’agit d’une tentative de XDG, une autre organisation standard orientée vers les environnements de bureau (comme Gnome, KDE et Unity), pour tenter de définir certaines conventions concernant la structure du domicile de l’utilisateur. Tous les logiciels ne s'y conforment pas (par exemple, ~/.local/bin n'est pas dans la valeur par défaut de l'utilisateur $PATH, alors que par logique cela devrait), et aucun utilisateur n'est obligé de le suivre, mais les deux bénéficient de nombreux avantages d'interopérabilité s'ils le font.

J'espère que cela aide à clarifier les choses un peu. N'hésitez pas à demander n'importe quoi pour 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 y a sûrement beaucoup d'inexactitudes, mais je crois que c'est un bon moyen de faire comprendre à un nouveau venu rationalités des répertoires)


135
2018-05-11 20:49



Vous l'avez résumé de manière très concise et oui, c'est vrai - la réponse complète est une histoire beaucoup plus longue que celle ci-dessus! - papashou
Pourquoi pas? La même logique s'applique: un attaquant peut créer un exécutable sous la maison ou un sous-répertoire de celui-ci, nommé d'après une commande système. - ignis
@ignis: si un attaquant a accès à la création et à la modification de fichiers sous la maison d'un utilisateur, cet utilisateur est déjà complètement compromis et $PATH n'est pas pertinent. L'attaquant peut même changer cette via ~/.profile, votre point est donc discutable. ~/.local/bin est aussi sûr (ou peu sûr, si vous voulez) que ~/bin, pratique courante dans la plupart des distributions. L'idée qu'un utilisateur ne devrait pas avoir tout dir pour garder et exécuter des scripts personnels dans $PATHest absurde. - MestreLion
Ainsi, ~/bin est aussi sûr que ~/.profile, et $PATH ne me protège pas contre les logiciels malveillants gérés par moi (qui ont la permission d'écrire chez moi). Je ne connaissais pas ce fichier, je suis désolé. Merci pour la clarification, désolé pour mon commentaire précédent. - ignis
Plus l’histoire est longue, plus l’amélioration / le désordre est important. - smwikipedia