Quelle est la différence entre / opt et / usr / local?

404

Selon la norme de hiérarchie du système de fichiers , il /opts'agit de "l'installation de progiciels d'application complémentaires". /usr/localest "à utiliser par l'administrateur système lors de l'installation du logiciel localement". Ces cas d'utilisation semblent assez similaires. Les logiciels qui ne sont pas inclus dans les distributions sont généralement configurés par défaut pour être installés dans l'un /usr/localou l' autre, /optsans rime particulière ni raison pour laquelle ils ont choisi.

Y a-t-il une différence qui me manque ou les deux font-ils la même chose, mais existent-ils pour des raisons historiques?

Les patchs
la source
3
D'après ce que j'ai compris, il /usr/locals'agit d'une version locale du /usrsystème de fichiers, alors qu'elle /optest réservée à divers éléments.
Yasouser
5
Question similaire dans Ask Ubuntu , super
kenchew
Hors sujet sur des raisons historiques: Comprendre la division bin, sbin, usr / bin, usr / sbin .
Alexey

Réponses:

357

Bien que les deux sont conçus pour contenir des fichiers ne faisant pas partie du système d'exploitation, /optet /usr/localne sont pas destinés à contenir le même ensemble de fichiers.

/usr/localest un emplacement pour installer les fichiers créés par l'administrateur, généralement à l'aide de la makecommande (par exemple, ./configure; make; make install). L'idée est d'éviter les conflits avec des fichiers faisant partie du système d'exploitation, qui pourraient être écrasés ou écrasés par des fichiers locaux sinon (par exemple, /usr/bin/foofait partie du système d'exploitation tout en /usr/local/bin/fooconstituant une alternative locale).

Tous les fichiers sous /usrpeuvent être partagés entre les instances de système d'exploitation, bien que cela soit rarement fait avec Linux. Ceci est une partie où la FHS est légèrement contradictoire, comme /usrdéfini en lecture seule, mais /usr/local/bindoit être en lecture-écriture pour que l'installation locale du logiciel réussisse. Le standard de système de fichiers SVR4, qui était la principale source d’inspiration de FHS, recommande d’éviter /usr/localet d’utiliser /opt/localplutôt pour surmonter ce problème.

/usr/localest un héritage de la BSD d'origine. À ce moment-là, le code source des /usr/bincommandes du système d' exploitation se trouvait dans /usr/src/binet /usr/src/usr.bin, tandis que la source des commandes développées localement se trouvait dans /usr/local/srcet leurs fichiers binaires dans /usr/local/bin. Il n'y avait aucune notion d'emballage (en dehors des archives).

D'autre part, /optest un répertoire pour l'installation de packages non groupés (c'est-à-dire que les packages ne font pas partie de la distribution du système d'exploitation, mais fournis par une source indépendante), chacun dans son propre sous-répertoire. Ils constituent déjà des packages complets fournis par un distributeur de logiciels tiers indépendant. Contrairement aux /usr/localchoses, ces paquets respectent les conventions de répertoires (ou du moins ils le devraient). Par exemple, someappserait installé dans /opt/someapp, avec l'une de ses commandes /opt/someapp/bin/foo, son fichier de configuration /etc/opt/someapp/foo.conf, ainsi que ses fichiers journaux /var/opt/someapp/logs/foo.access.

jlliagre
la source
53
/ usr / local, pour les logiciels autonomes, compilés et maintenus. / opt est destiné à la zone d'installation de bundle d'application / binaire externe non-auto, externe. Hmmm ... nous n'avons pas de fichiers programme C: \ pour tout ;-)
Nikhil Mulley
2
"D'autre part, / opt est un répertoire où installer des packages dégroupés". Que signifient les packages "dégroupés" ici?
Kevin Wheeler
1
@ KevinWheeler Cela est expliqué dans la phrase suivante. Unbundled signifie que les packages ne font pas partie de la distribution du système d'exploitation mais sont fournis par une source indépendante.
jlliagre
2
@jlliagre the centos docs * state "Par exemple, si le répertoire / usr / est monté en tant que partage NFS en lecture seule à partir d'un hôte distant, il est toujours possible d'installer un package ou un programme dans le répertoire / usr / local /" Je ne sais pas qui a raison, mais cela semble être en contradiction avec ce que vous affirmez dans un domaine où FHS est faible. (* source centos.org/docs/5/html/5.1/Deployment_Guide/… )
Kevin Wheeler
1
@ KevinWheeler C'est précisément la faiblesse dont je parle. L'installation d'un paquet ou d'un programme dans un répertoire distant en lecture seule est tout simplement impossible. La solution de contournement serait de monter un système de fichiers local sur / usr / local, mais cela ressemble plus à un travail de fortune qu'à un travail correctement conçu.
jlliagre
84

La différence fondamentale réside dans le /usr/localfait que les logiciels ne sont pas gérés par le gestionnaire de programmes, mais respectent néanmoins les règles de déploiement Unix standard.

C'est pourquoi vous avez /usr/local/bin, /usr/local/sbin /usr/local/includeetc ...

/optd'autre part, c'est un logiciel qui ne suit pas cela et qui est déployé de manière monolithique. Cela inclut généralement des logiciels commerciaux et / ou multiplates-formes présentés dans le style "Windows".

Laisse-moi tranquille
la source
12
Je ne suis pas d'accord sur votre point monolithique. La norme FHS stipule que les packages installés dans les sous-répertoires / opt doivent avoir leurs fichiers spécifiques à l’hôte situés en dehors de / opt, respectivement sous / etc / opt / package pour les fichiers de configuration et / var / opt / package pour les journaux, spool, etc. / opt est en réalité plus proche des règles de déploiement Unix que / usr / local, qui place tout dans un répertoire qui doit être en lecture seule mais ne peut l'être pour des raisons évidentes.
Juillet
5
Bien sûr, si je faisais un paquet opt ​​et que je voulais revendiquer la conformité FHS. Sinon, la norme correspond davantage à ce que vous appelleriez des "lignes directrices". Ce n’est pas parce que NetBeans n’utilise pas / etc / opt / netbeans que je vais le placer dans / opt pour l’ensemble du système ou $ HOME / .local / opt pour un utilisateur unique.
jla
1
@jla Je suppose que votre dernier commentaire m'a été adressé. Veuillez donc utiliser @ xxx lorsque vous répondez à quelqu'un d'autre que l'OP ou l'auteur de la réponse. À propos de / etc / opt, la FHS ne dit pas que c'est un emplacement recommandé (à titre indicatif), mais obligatoire. Les développeurs Netbeans et vous-même êtes libres de violer cette norme car il n’existe aucune autorité pour l’appliquer, mais il ne faut pas se tromper. C'est simplement un malentendu malheureux ou une violation délibérée.
Juillet
8
@jlliagre En tant qu'administrateur de mon système, le FHS est un ensemble de directives. Le répertoire / opt est l’endroit bien établi du bon sens pour installer un logiciel monolithique / opt / <package> ou / opt / <fournisseur>. Lorsque j'installe un package qui souhaite utiliser <package | provider> / all / data / required / to / support, il entre dans opt / même si le fournisseur ne parvient pas à suivre tous les détails de la dernière FHS. Je pourrais envoyer un email ou signaler un bogue, mais je ne vais pas mettre ce paquet monolithique ailleurs pour me sentir mieux avec FHS sur mon système.
jla
1
@jlliagre J'ai installé plein de choses dans / opt et aucun fichier n'est créé dans / etc / opt. Devrait?
erm3nda
18

Ils sont très similaires et l’utilisation de l’un ou de l’autre est plus une question d’opinion. Le journal Linux a eu cette discussion point / contrepoint sur ce sujet précis ici .

philfr
la source
9
Oh cher. Je ne voulais pas me traîner dans une "guerre sainte".
Patchs du
13

Pour moi, personnellement, c'est ce que Bill a dit dans le lien de @ philfr:

Sur un système de développement, ou un bac à sable, disposer d'un répertoire / opt où vous pouvez simplement lancer des éléments et voir s'ils fonctionnent est d'une grande utilité. Je sais que je ne vais pas faire l'effort d'emballer les choses moi-même pour les essayer. Si l'application ne fonctionne pas, vous pouvez simplement entrer le répertoire / opt / mytestapp et cette application appartient à l'historique. L'emballage peut avoir du sens lorsque vous exécutez un déploiement volumineux (parfois, je fais des applications en package), mais souvent, il est agréable d'ajouter des éléments dans / opt.

Malheureusement, la plupart des make installscripts insèrent des fichiers au /usr/locallieu de simplement créer un lien symbolique: - /

Pepoluan
la source
2
Quel serait le but? Si vous voulez quand même créer le lien symbolique, pourquoi ne pas simplement y placer le fichier original?
Let_Me_Be
8
Juste pour commenter la make installcible poussant des fichiers dans /usr/local; cette fonctionnalité est facilement modifiable en passant un --prefix=paramètre de ligne de commande au ./configurescript ou s'il n'y a pas de ./configurescript, vous pouvez passer un paramètre à la makecible comme ceci: make --prefix=/usr install.
Sean C.
3
Est-ce que / opt est un répertoire standard inclus dans $ PATH? Je sais que / usr / local est.
LawrenceC
6
@ Let_Me_Be l'avantage serait qu'il est très facile de conserver les anciennes versions. Disons que j'ai 2 versions de 'foo', situées dans /opt/foo-1.1et /opt/foo-1.2. Lorsque je mets à niveau, le foolien symbolique dans /usr/local/binpointer vers foo-1.2. Si, pour une raison quelconque, je dois revenir en arrière, je remplace simplement le lien symbolique par un lien qui pointe vers foo-1.1. Si 1.2 est correct après plusieurs semaines, un rapide rm -rf /opt/foo-1.1enlève l'ancienne version rapidement et proprement.
pepoluan
7
@ultrasawblade Non, ce n'est pas. et ne devrait jamais l'être. Après tout, selon FHS, / opt doit être subdivisé en sous-répertoires portant le nom du package. tout entasser dans PATH est un moyen infaillible de mener au désastre. les applications doivent plutôt s'installer elles-mêmes sous / opt, et relier symboliquement leurs programmes invoqués par l'utilisateur vers / usr / local / bin (ou sbin).
pepoluan
11

Premièrement, je ne pense pas qu'il y ait une réponse stricte; différents administrateurs auront des opinions différentes, en fonction de leurs antécédents. Historiquement, /usr/localest venu en premier; c'était la convention à Berkley, IIRC. À un moment donné au cours du développement de System V, si je ne me trompe pas (tout cela remonte à longtemps et je n'ai pas pris de notes), il y a eu une décision ou un désir de pouvoir monter en /usrlecture seule, ce qui signifiait que vous ne pouviez pas ajouter de nouveau logiciel; c'est peut-être pour cette raison qu'il a /opt été inventé. En l'occurrence, il y avait tellement de logiciels existants qui écrivaient /usrque cette idée n'avait jamais vraiment pris forme.

Ma préférence personnelle est /opt, avec un sous-répertoire distinct pour chaque produit; cela facilite la suppression d'un produit rm -fr. Mais si tout votre logiciel est installé via un bon gestionnaire de paquets, peu importe, et si le logiciel que vous installez ne respecte pas strictement ces conventions, et écrit des configurations, etc. /usr, cela n'a pas d'importance, bien que pour les raisons opposées.

James Kanze
la source
1
"" "tous vos logiciels sont installés via un bon gestionnaire de paquets" "", ce qui est impossible si vous n'utilisez que des logiciels fréquemment utilisés.
Pacerier
1
@ Pacerier c'est possible, cela dépend de la distribution que vous utilisez. Quel que soit le logiciel utilisé, il se trouve probablement dans le référentiel utilisateur Arch. Dans le cas contraire, PKGBUILD est relativement facile à écrire.
StarlitGhost
9

J'ai un point de vue légèrement différent sur cette question.
Bien que la réponse de jlliagre soit correcte, l’application pratique pour moi, lors du déploiement de logiciels dans un cluster, se résume aux variables d’environnement par défaut et à la réutilisation par défaut des bibliothèques.

En termes simples - /usr/localet tous ses répertoires enfants se trouvent dans les variables env appropriées, telles que PATHet MANPATH, et se /usr/local/lib{,64}trouvent dans ldconfig's ( /etc/ld.so.conf.d/).

/opt/OTOH n’est pas - ce qui est avantageux à la fois lorsque plusieurs versions ou des packages en conflit sont nécessaires pour coexister dans le système, mais nécessite une sorte de gestion de l’environnement (par exemple, des modules d’environnement ou des collections de logiciels ), et désavantageux dans le sens où cela risquerait de "gaspiller "espace de stockage en dupliquant les bibliothèques partagées, chaque installation /optpouvant être complètement autonome.

Pour que la nature partagée /usr/localfonctionne /usr/local/bincorrectement , on suppose par exemple que les fichiers binaires sont installés directement sur (et les pages de manuel sur appropriées /usr/local/share/man/...) plutôt que sur /usr/local/app/{bin,share/man,...}etc.

Dani_l
la source