Nuestro administrador del sistema instaló una aplicación de software (Maven) en el servidor y les dijo a todos que agregaran la /usr/local/maven/bin/carpeta a su ruta.
Creo que podría ser más conveniente simplemente vincular los pocos programas en esa carpeta desde la /bincarpeta (u otra carpeta que todos tengan en su camino) de esta manera:
ln -s /usr/local/maven/bin/* /bin
¿Es esto correcto? ¿Hay algunos efectos secundarios ocultos en mi sugerencia?
Respuestas:
Por lo general, no se vinculan /usr/local/*con /bin, pero esto es más bien una práctica histórica. En general, hay algunas razones "técnicas" por las que no puede hacer lo que sugiere.
Hacer enlaces a ejecutables en /binpuede causar problemas:
Probablemente la mayor advertencia sería si su sistema tiene paquetes administrados por algún tipo de administrador de paquetes como RPM, dpkg, APT, YUM, pacman, pkg_add, etc. En estos casos, generalmente querrá dejar el paquete gerente de hacer su trabajo y administrar directorios, tales como /sbin, /bin, /lib, y /usr. Una excepción sería, por /usr/locallo general, un lugar seguro para hacer lo que mejor le parezca en la caja, sin tener que preocuparse de que un administrador de paquetes interfiera con sus archivos.
Muchas veces los ejecutables creados para /usr/localtendrán esta RUTA codificada en sus ejecutables. También puede haber archivos de configuración que se incluyen /usr/localcomo parte de la instalación de estas aplicaciones. Por lo tanto, vincular solo el ejecutable podría causar problemas con estas aplicaciones para encontrar los .cfgarchivos más tarde. Aquí hay un ejemplo de tal caso:
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
El mismo problema que se aplica a la búsqueda de .cfgarchivos también puede ocurrir con ejecutables "auxiliares" que la aplicación principal necesita para ejecutarse. También sería necesario vincularlos /usr/bin, sabiendo que esto podría ser problemático y solo aparecería cuando realmente intentara ejecutar la aplicación vinculada.
NOTA: en general, es mejor evitar la tentación de vincular aplicaciones únicas /usr/bin.
En lugar de que todos los usuarios proporcionen esta administración, el administrador podría agregar esto fácilmente a todos $PATHen el cuadro agregando un archivo correspondiente en el /etc/profile.ddirectorio.
Un archivo como este /etc/profile.d/maven.sh:
PATH=$PATH:/usr/local/maven/bin
Por lo general, haces esto como administrador en lugar de contaminar todas las configuraciones de los usuarios con esto.
La mayoría de las distribuciones ahora proporcionan otra herramienta llamada alternatives(Fedora / CentOS) o update-alternatives(Debian / Ubuntu) que también puede usar para acceder a las $PATHherramientas que podrían estar fuera del /bin. Es preferible utilizar herramientas como estas, ya que se adhieren más a lo que la mayoría de los administradores considerarían "práctica estándar" y, por lo tanto, hace que los sistemas sean más fáciles de transferir de un administrador a otro.
Esta herramienta hace algo similar al crear enlaces /bin; pero gestiona la creación y destrucción de estos enlaces, por lo que es más fácil comprender la configuración prevista de un sistema cuando se realiza a través de una herramienta en lugar de hacerlo directamente como sugiere.
Aquí estoy usando ese sistema para administrar Java de Oracle en una caja:
$ 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
Puedes ver los efectos de esto:
$ 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
Hacer enlaces /bin, aunque sea plausible, probablemente sería muy desalentado por la mayoría de los administradores de sistemas:
/bindirectorio. Aquí hay un ejemplo. En las distribuciones de Red Hat que utilizan RPM si un archivo ya existe en /binRPM no se instalará como se ha descrito, a menos que sea necesario hacerlo mediante el --replacefilesinterruptor. Entonces esa no es realmente una razón técnica. Lo mismo con otros directorios. Entiendo lo que estás diciendo sobre el "propietario" del sistema operativo, /binpero no es tan claro como estás diciendo.
Respondiendo a las preguntas formuladas:
¿Es esto correcto?
No , es una mala práctica.
¿Hay algunos efectos secundarios ocultos en mi sugerencia?
Sí, hay varios efectos secundarios. Su sugerencia podría funcionar o no dependiendo de la aplicación, y podría retroceder o romperse a largo plazo.
Hay razones razonables para no crear un enlace tan simbólico:
Los administradores no "poseen" /bin(ver nota 1) ya que este directorio pertenece a los desarrolladores del sistema operativo / distribución. Por otro lado, /usr/locales una ubicación tradicional para el software creado por el administrador local, que /opt/<packagename>es una para el software desagregado. Si crea un archivo o un enlace /bin, existe el riesgo de que se sobrescriba mediante la instalación de un paquete, en su caso, un mavenpaquete hipotético proporcionado por el sistema operativo, lo que podría provocar una regresión si el creado localmente se crea a partir de una versión más reciente código fuente que la versión del sistema operativo. Por ejemplo, los tarballs SVR4 pkgadd, debian dpkg, red-hat rpmy slackware sobrescribirán ciegamente su enlace simbólico.
Algunas aplicaciones miran al lugar donde se les llama para recuperar archivos de configuración, complementos y recursos similares. Si llama a la aplicación por un enlace simbólico, es posible que su código no pueda seguirla y luego busque estos archivos de recursos /usr/bindonde no están.
Puede haber otros archivos binarios Se eliminó porque ya tiene eso en cuenta con su comando al vincular todos los comandos potenciales./usr/local/maven/biny no agregar este directorio a su RUTA hará que no estén disponibles.
La página de maven2 le dice que agregue este directorio a su RUTA (precisamente: Agregue la variable de entorno M2 a su ruta, por ejemplo, exportar RUTA = $ M2: $ RUTA ), al usar un enfoque diferente, está rompiendo ese paso, por lo que no se admite. camino. Por supuesto, si la mayoría de los usuarios de un sistema son mavenusuarios potenciales , tendría más sentido configurarlo PATHglobalmente que en todos y cada uno .profile.
Nota 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.
Estándar de jerarquía de Debian / sistema de archivos
/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.
La prueba simple que muestra Debian dpkgno conserva un enlace existente, incluso cuando la --force-overwriteopción no se utiliza:
# 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
/bino /usr/bin. Al descubrir los problemas de los binarios del sistema ocultos o destruidos (el más famoso fue test), se adoptó progresivamente la mejor práctica para instalar binarios que no son del sistema en otro lugar.
Si desea un enlace simbólico, sería mejor hacerlo /usr/local/bin. En mi servidor, solía instalar software local /opt/NAMEy vincular los archivos binarios a /usr/local/bin.
Una alternativa a los dos métodos sugeridos es crear un script de shell en el /usr/local/binque, cuando se ejecute, ejecute cualquier binario que especifique en el script. Por ejemplo, usando maven como ejemplo, crearía un script de shell en /usr/local/binllamado mavenque tiene un pequeño script dentro para ejecutar el binario de maven donde está ubicado y pasarle cualquier argumento:
#!/bin/sh
exec /usr/local/maven/bin/maven "$@"
Esto tiene la desventaja de tener que hacer esto para cada binario que desea "vincular", pero le permite llamar a esos binarios desde la línea de comandos sin necesidad de acumular su $PATHvariable de entorno.
/opt.