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 à leur chemin.
Je pense qu'il pourrait être plus pratique de simplement lier les quelques programmes de ce dossier à partir du /bindossier (ou d'un 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?
Réponses:
Vous ne vous liez généralement pas /usr/local/*avec /bin, mais c'est plus une pratique historique. En général, il y a quelques raisons "techniques" pour lesquelles vous ne pouvez pas faire ce que vous proposez.
La création de liens vers des exécutables dans /binpeut provoquer 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 des répertoires tels que gestionnaire faire son travail et à gérer /sbin, /bin, /libet /usr. Une exception serait /usr/localgénéralement un endroit sûr pour faire ce que vous jugez bon sur la boîte, sans avoir à vous soucier d'un gestionnaire de paquets qui interfère avec vos fichiers.
Souvent, les exécutables construits pour /usr/localauront ce PATH codé en dur dans leurs exécutables. Certains fichiers de configuration peuvent également être inclus dans /usr/localle cadre de l'installation de ces applications. Ainsi, la liaison à l'exécutable peut entraîner des problèmes avec ces applications pour trouver les .cfgfichiers ultérieurement. 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 .cfgfichiers peut également se produire avec les exécutables "d'assistance" que l'application principale doit exécuter. Ceux-ci devraient également être liés /usr/bin, sachant que cela pourrait ê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.
Plutôt alors que tous les utilisateurs fournissent cette gestion, l'administrateur pourrait très facilement l'ajouter à tout le monde $PATHsur la boîte en ajoutant un fichier correspondant dans le /etc/profile.dré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.
La plupart des distributions fournissent maintenant un autre outil appelé alternatives(Fedora / CentOS) ou update-alternatives(Debian / Ubuntu) que vous pouvez également utiliser pour boucler dans les $PATHoutils qui pourraient être 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 à transférer d'un administrateur à un autre.
Cet outil fait une chose similaire 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 le Java d'Oracle 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
L'établissement de liens /bin, bien que plausible, serait probablement fortement découragé par la plupart des administrateurs système:
/binrépertoire. Voici un exemple. Sur Red Hat, les distributions qui utilisent RPM si un fichier existe déjà dans /binRPM ne s'installeront pas comme vous l'avez décrit, sauf si elles sont obligées de le faire à l'aide du --replacefilescommutateur. Ce n'est donc pas vraiment une raison technique. Même chose avec les autres répertoires. Je comprends ce que vous dites à propos du "propriétaire" du système d'exploitation, /binmais ce n'est pas aussi clair que vous le dites.
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 y a des raisons raisonnables de ne pas créer un tel lien symbolique:
Les administrateurs ne sont pas "propriétaires" /bin(voir note 1) car ce répertoire appartient aux développeurs de systèmes d'exploitation / de distribution. D'autre part, il /usr/locals'agit d'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 /bindedans, il y a un risque qu'il soit écrasé par une installation de package, dans votre cas un mavenpackage hypothétique fourni par le système d'exploitation, ce qui peut conduire à une régression si celui construit localement est créé à partir de plus récents code source que la version du système d'exploitation. Par exemple, les tarballs SVR4 pkgadd, debian dpkg, red-hat rpmet 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 là /usr/binoù ils ne se trouvent pas.
Il peut y avoir d'autres fichiers binaires Supprimé car vous prenez déjà cela en compte avec votre commande en liant toutes les commandes potentielles./usr/local/maven/binet ne pas ajouter ce répertoire à votre PATH les rendra indisponibles.
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 interrompez cette étape, vous passez donc sans support façon. Bien sûr, si la plupart des utilisateurs d'un système sont des mavenutilisateurs potentiels , il serait plus logique de définir PATHglobalement plutôt que sur chacun .profile.
Note 1:
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.
Norme de hiérarchie Debian / système de fichiers
/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
/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 que Debian dpkgne conserve pas un lien existant, même si l' --force-overwriteoption 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
/binou /usr/bin. Après avoir découvert les problèmes des binaires système cachés ou détruits (le plus célèbre était test), la meilleure pratique pour installer des binaires non système ailleurs a été progressivement adoptée.
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 /opt/NAMEet de créer des liens symboliques vers les fichiers binaires /usr/local/bin.
Une alternative aux deux méthodes suggérées consiste à créer un script shell dans le /usr/local/binsens où, une fois exécuté, il 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/binappelé mavenqui a un petit script à l'intérieur 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 fichiers binaires à partir de la ligne de commande sans avoir à nettoyer votre $PATHvariable d'environnement.
/opt.