Ajout au chemin vs liaison depuis / bin

Question

Notre administrateur système a installé une application logicielle (Maven) sur le serveur et a dit à tout le monde d'ajouter le /usr/local/maven/bin/ dossier vers leur chemin.

Je pense qu'il pourrait être plus pratique de simplement lier les quelques programmes de ce dossier à partir de /bin dossier (ou autre dossier que tout le monde a sur son chemin) comme ceci:

ln -s /usr/local/maven/bin/* /bin

Est-ce correct? Y a-t-il des effets secondaires cachés à ma suggestion?

slm · Accepted Answer

Sur la liaison

Vous ne liez généralement pas /usr/local/* avec /bin, mais il s'agit plus d'une pratique historique. En général, il y a quelques raisons "techniques" pour lesquelles vous ne pouvez pas faire ce que vous proposez.

Création de liens vers des exécutables dans /bin peut causer des problèmes:

La plus grande mise en garde serait probablement si votre système a des packages gérés par une sorte de gestionnaire de packages tels que RPM, dpkg, APT, YUM, pacman, pkg_add, etc. Dans ces cas, vous voudrez généralement laisser le package gestionnaire fait son travail et gère des répertoires tels que /sbin, /bin, /lib, et /usr. Une exception serait /usr/local qui est généralement un endroit sûr pour faire comme bon vous semble sur la boîte, sans avoir à vous soucier qu'un gestionnaire de paquets interfère avec vos fichiers.
Souvent, les exécutables construits pour /usr/local aura ce CHEMIN codé en dur dans leurs exécutables. Des fichiers de configuration peuvent également être inclus dans /usr/local dans le cadre de l'installation de ces applications. Un lien vers l'exécutable peut donc entraîner des problèmes avec ces applications qui trouvent le .cfg fichiers plus tard. Voici un exemple d'un tel cas:
```
$ strings /usr/local/bin/wit | grep '/usr/local' /usr/local/share/wit /usr/local/share/wit/ 
```
Le même problème qui s'applique à la recherche de .cfg les fichiers peuvent également se produire avec des exécutables "auxiliaires" que l'application principale doit exécuter. Ceux-ci devraient également être liés à /usr/bin, sachant que cela peut être problématique et n'apparaître que lorsque vous avez réellement tenté d'exécuter l'application liée.

REMARQUE: en général, il est préférable d'éviter la tentation de créer un lien vers des applications uniques dans /usr/bin.

/etc/profile.d

Plutôt alors que tous les utilisateurs fournissent cette gestion, l'administrateur pourrait très facilement l'ajouter au $PATH sur la boîte en ajoutant un fichier correspondant dans le /etc/profile.d répertoire.

Un fichier comme celui-ci, /etc/profile.d/maven.sh:

PATH=$PATH:/usr/local/maven/bin

Vous le faites généralement en tant qu'administrateur au lieu de polluer toutes les configurations des utilisateurs avec cela.

Utiliser des alternatives

La plupart des distributions fournissent désormais un autre outil appelé alternatives (Fedora/CentOS) ou update-alternatives (Debian/Ubuntu) que vous pouvez également utiliser pour boucler dans le $PATH outils pouvant se trouver en dehors de /bin. L'utilisation d'outils tels que ceux-ci est préférable car ils adhèrent davantage à ce que la plupart des administrateurs considéreraient comme une "pratique standard" et rendent ainsi les systèmes plus faciles à passer d'un administrateur à un autre.

Cet outil fait la même chose en créant des liens dans /bin; mais il gère la création et la destruction de ces liens, il est donc plus facile de comprendre la configuration prévue d'un système lorsqu'elle est effectuée à l'aide d'un outil par rapport à celle effectuée directement comme vous le suggérez.

Ici, j'utilise ce système pour gérer Oracle Java sur une boîte:

$ ls -l /etc/alternatives/ | grep " Java" lrwxrwxrwx. 1 root root 73 Feb 5 13:15 Java -> /usr/lib/jvm/Java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/Java lrwxrwxrwx. 1 root root 77 Feb 5 13:15 Java.1.gz -> /usr/share/man/man1/Java-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz lrwxrwxrwx. 1 root root 70 Feb 5 13:19 javac -> /usr/lib/jvm/Java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javac lrwxrwxrwx. 1 root root 78 Feb 5 13:19 javac.1.gz -> /usr/share/man/man1/javac-Java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz lrwxrwxrwx. 1 root root 72 Feb 5 13:19 javadoc -> /usr/lib/jvm/Java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javadoc lrwxrwxrwx. 1 root root 80 Feb 5 13:19 javadoc.1.gz -> /usr/share/man/man1/javadoc-Java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz

Vous pouvez voir les effets de ceci:

$ type Java java is /usr/bin/Java $ readlink -f /usr/bin/Java /usr/lib/jvm/Java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/Java

Mon 0,02 $

Création de liens dans /bin, bien que plausible, serait probablement fortement découragé par la plupart des administrateurs système:

Serait mal vu car il est considéré comme personnalisé et peut prêter à confusion si un autre administrateur est requis pour ramasser la boîte
Peut conduire à la rupture d'un système dans un état futur suite à cette personnalisation "fragile".

jlliagre · Answer

Répondre aux questions posées:

Est-ce correct?

Non , c'est une mauvaise pratique.

Y a-t-il des effets secondaires cachés à ma suggestion?

Oui il y a plusieurs effets secondaires. Votre suggestion peut fonctionner ou non en fonction de l'application, et peut régresser ou être interrompue à long terme.

Il existe des raisons raisonnables de ne pas créer un tel lien symbolique:

Les administrateurs ne "possèdent" pas /bin (Voir remarque 1) car ce répertoire appartient aux développeurs du système d'exploitation/distribution. D'autre part, /usr/local Est un emplacement traditionnel pour les logiciels créés par l'administrateur local, /opt/<packagename> Étant un emplacement pour les logiciels dégroupés. Si vous créez un fichier ou un lien dans /bin, Il y a un risque qu'il soit écrasé par une installation de package, dans votre cas un package hypothétique maven fourni par le système d'exploitation, qui pourrait conduire à une régression si celui construit localement est créé à partir d'un code source plus récent que la version du système d'exploitation. Par exemple, SVR4 pkgadd, debian dpkg, red-hat rpm et les tarballs slackware écraseront aveuglément votre lien symbolique.
Certaines applications recherchent l'endroit où elles sont appelées pour récupérer les fichiers de configuration, les plugins et les ressources similaires. Si vous appelez l'application par un lien symbolique, son code risque de ne pas la suivre, puis de rechercher ces fichiers de ressources autour de /usr/bin Où ils ne le sont pas.
~~Il peut y avoir d'autres binaires dans /usr/local/maven/bin Et ne pas ajouter ce répertoire à votre PATH les rendra indisponibles.~~ Supprimé car vous prenez déjà cela en compte avec votre commande en liant toutes les commandes potentielles.
La page maven2 indique d'ajouter ce répertoire à votre PATH (précisément: Ajoutez la variable d'environnement M2 à votre chemin, par exemple, exportez PATH = $ M2: $ PATH .), En utilisant une approche différente, vous franchissez cette étape, vous allez donc d'une manière non prise en charge. Bien sûr, si la plupart des utilisateurs d'un système sont des utilisateurs potentiels de maven, il serait plus logique de définir le PATH globalement plutôt que sur chaque .profile.

Note 1:

Documentation Slackware:

 The /bin directory usually doesn't receive modification after installation. If it does, it's usually in the form of package upgrades that we provide.

Debian/Filesystem Hierarchy Standard

/bin/ Essential command executable (binaries) for all users (e.g., cat, ls, cp) (especially files required to boot or rescue the system) ... /opt/ Add-on application software packages Pre-compiled, non ".deb" binary distribution (tar'ed..) goes here. /opt/bin/ Same as for top-level hierarchy

documentation Solaris:

/usr/bin Platform-dependent, user-invoked executables. These are commands users expect to be run as part of their normal $PATH. For executables that are different on a 64-bit system than on a 32-bit system, a wrapper that selects the appropriate executable is placed here. See isaexec(3C). An approved installation location for bun- dled Solaris software. The analogous location for add-on system software or for applications is /opt/packagename/bin.

Un test simple montrant dpkg de Debian ne conserve pas un lien existant, même si l'option --force-overwrite N'est pas utilisée:

# ls -l /usr/bin/banner lrwxrwxrwx 1 root root 11 Feb 25 21:37 /usr/bin/banner -> /tmp/banner # dpkg -i sysvbanner_1.0.15_AMD64.deb Selecting previously unselected package sysvbanner. (Reading database ... 236250 files and directories currently installed.) Unpacking sysvbanner (from sysvbanner_1.0.15_AMD64.deb) ... Setting up sysvbanner (1.0.15) ... Processing triggers for man-db ... # ls -l /usr/bin/banner -rwxr-xr-x 1 root root 11352 May 7 2009 /usr/bin/banner

nyuszika7h · Answer

Si vous souhaitez créer un lien symbolique, il serait préférable de créer un lien symbolique vers /usr/local/bin. Sur mon serveur, j'avais l'habitude d'installer des logiciels locaux dans /opt/NAME et créer un lien symbolique entre les fichiers binaires et /usr/local/bin.

wheeler · Answer

Une alternative aux deux méthodes suggérées consiste à créer un script Shell dans /usr/local/bin qui, une fois exécuté, exécute le binaire que vous spécifiez dans le script. Par exemple, en utilisant maven comme exemple, je créerais un script Shell dans /usr/local/bin appelé maven qui contient un petit script pour exécuter le binaire maven où il se trouve et lui passer tous les arguments:

#!/bin/sh exec /usr/local/maven/bin/maven "$@"

Cela a l'inconvénient d'avoir à le faire pour chaque binaire que vous souhaitez "lier", mais cela vous permet d'appeler ces binaires à partir de la ligne de commande sans avoir à nettoyer votre $PATH variable d'environnement.