Agregar a la ruta frente a vincular desde / bin

24

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?

symlink path directory-structure Erel Segal-Halevi
fuente
2
Por LSB debe agregar paquetes externos debajo /opt.
vonbrand

Respuestas:

31

En la vinculación

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:

  1. 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.

  2. 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/

  3. 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.

/etc/profile.d

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.

Usando alternativas

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

Mi $ 0.02

Hacer enlaces /bin, aunque sea plausible, probablemente sería muy desalentado por la mayoría de los administradores de sistemas:

  1. Sería mal visto porque se ve como personalizado y puede generar confusión si se requiere que otro administrador levante la caja
  2. Puede provocar que un sistema se rompa en un estado futuro como resultado de esta personalización "frágil".
slm
fuente
@slm Es posible que desee modificar su primer párrafo. Hay varias razones técnicas para no usar un enlace simbólico.
jlliagre
@jlliagre: al mirar su A no estoy convencido de que los administradores no sean dueños del /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.
slm
@jlliagre: también en mi A, no estoy alentando a nadie a crear un enlace, simplemente declaro que pueden hacerlo si así lo desean. Odio los sistemas en los que las cosas se hacen así y, por lo general, maldigo al administrador que lo hizo 8-).
slm
@slm Pueden (ya que tienen suficientes privilegios) pero eso no implica que esto funcione. Los puntos 2 y 3 de mi respuesta siguen siendo razones técnicas válidas para no crear un enlace, sino para usar la RUTA correcta, especialmente en el caso de OP. Le animo a que los mencione en su respuesta.
jlliagre
@jlliagre: detalles agregados según sus comentarios.
slm
7

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 /usr/local/maven/biny no agregar este directorio a su RUTA hará que no estén disponibles. Se eliminó porque ya tiene eso en cuenta con su comando al vincular todos los comandos potenciales.

  • 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:

Documentación de 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.

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

Documentación de 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.

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
jlliagre
fuente
Importante de hecho. Es bastante desafortunado que hayas aceptado una respuesta que dice incorrectamente que es solo una práctica histórica sin razones técnicas para evitar ...
jlliagre
1
Tiene razón, pero acepté esa respuesta porque me dio una solución práctica que utilicé, que es decirle al administrador del sistema que coloque el comando de modificación PATH en /etc/profile.d.
Erel Segal-Halevi
Estoy de acuerdo en que dio una solución práctica y correcta, pero no a las dos preguntas que hizo ("¿Es esto correcto? ¿Hay efectos secundarios?").
jlliagre
1
jlliagre tiene toda la razón. Esta práctica no es histórica en absoluto. Es más bien una mejor práctica reciente. Por el contrario, en los viejos Unixes, todos instalaban su software directamente en /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.
dan
3

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.

nyuszika7h
fuente
0

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.

rodador
fuente