Adicionando ao caminho vs. ligando de / bin

Question

Nosso administrador de sistemas instalou um aplicativo de software (Maven) no servidor e disse a todos que adicionassem a pasta /usr/local/maven/bin/ ao caminho deles.

Acho que seria mais conveniente apenas vincular os poucos programas dessa pasta da pasta /bin (ou outra pasta que todos tenham no caminho):

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

Isso está correto? Existem alguns efeitos colaterais ocultos à minha sugestão?

    

Answer 1

Ligando

Você geralmente não vincula /usr/local/* a /bin , mas isso é mais uma prática histórica. Em geral, existem alguns motivos "técnicos" para você não conseguir fazer o que está sugerindo.

Fazer links para executáveis em /bin pode causar problemas:

1. Provavelmente, a maior advertência seria se o seu sistema está tendo pacotes gerenciados por algum tipo de gerenciador de pacotes, como RPM, dpkg, APT, YUM, pacman, pkg_add, etc. Nesses casos, você geralmente quer deixar o gerenciador de pacotes fazer seu trabalho e gerenciar diretórios como /sbin , /bin , /lib e /usr . Uma exceção seria /usr/local , que normalmente é um local seguro para fazer o que você achar melhor na caixa, sem ter que se preocupar com o fato de um gerenciador de pacotes interferir em seus arquivos.

2. Muitas vezes, os executáveis criados para /usr/local terão esse PATH codificado em seus executáveis. Também pode haver arquivos de configuração incluídos em /usr/local como parte da instalação desses aplicativos. Portanto, vincular apenas ao executável pode causar problemas com esses aplicativos, encontrando os arquivos .cfg posteriormente. Aqui está um exemplo de tal caso:

   $ strings /usr/local/bin/wit | grep '/usr/local'
   /usr/local/share/wit
   /usr/local/share/wit/
   

3. O mesmo problema que se aplica à localização de arquivos .cfg também pode ocorrer com executáveis "auxiliares" que o aplicativo principal precisa executar. Eles também precisariam estar vinculados em /usr/bin , sabendo que isso pode ser problemático e só aparecer quando você realmente tentou executar o aplicativo vinculado.

OBSERVAÇÃO: em geral, é melhor evitar a tentação de vincular aplicativos únicos em /usr/bin .

/etc/profile.d

Em vez de todos os usuários fornecerem esse gerenciamento, o administrador poderia facilmente adicioná-lo a todos os $PATH da caixa adicionando um arquivo correspondente no diretório /etc/profile.d .

Um arquivo como este, /etc/profile.d/maven.sh :

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

Você geralmente faz isso como administrador, em vez de poluir todas as configurações dos usuários com isso.

Usando alternativas

A maioria das distros agora fornece outra ferramenta chamada alternatives (Fedora / CentOS) ou update-alternatives (Debian / Ubuntu) que você também pode usar para fazer o loop nas ferramentas $PATH que podem estar fora do /bin . O uso de ferramentas como essas é preferível, já que elas estão aderindo mais ao que a maioria dos administradores consideraria "prática padrão" e, assim, torna os sistemas mais fáceis de serem transferidos de um administrador para outro.

Esta ferramenta faz uma coisa semelhante ao criar links em /bin ; mas gerencia a criação e a destruição desses links, por isso é mais fácil entender a configuração pretendida de um sistema quando feita por meio de uma ferramenta, em comparação com o que você está sugerindo diretamente.

Aqui estou usando esse sistema para gerenciar o Java da Oracle em uma caixa:

$ 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

Você pode ver os efeitos disso:

$ 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

Meus US $ 0,02

Fazer links em /bin , embora plausíveis, provavelmente seria altamente desencorajado pela maioria dos administradores de sistema:

1. Será desaprovado porque é visto como personalizado e pode gerar confusão se outro administrador precisar pegar a caixa
2. Pode levar a que um sistema seja corrompido em um estado futuro como resultado dessa personalização "frágil".

Answer 2

Respondendo às perguntas feitas:

Is this correct?

Não , é uma prática ruim.

Are there some hidden side-effects to my suggestion?

Sim existem vários efeitos colaterais. Sua sugestão pode funcionar ou não, dependendo da aplicação, e pode regredir ou ser quebrada a longo prazo.

Existem razões sensatas não para criar um link simbólico:

• Os administradores não "possuem" /bin (consulte a nota 1), pois esse diretório pertence aos desenvolvedores do sistema operacional / distribuição. Por outro lado, /usr/local é uma localização tradicional para software construído pelo administrador local, /opt/<packagename> sendo um para o software desagrupado. Se você criar um arquivo ou um link em /bin , existe o risco de ser substituído por uma instalação de pacote, no seu caso, um pacote maven hipotético fornecido pelo SO, o que pode levar a uma regressão, se for o caso. construído localmente é criado a partir de código-fonte mais recente que a versão do sistema operacional. Por exemplo, os tarballs SVR4 pkgadd , debian dpkg , red-hat rpm e slackware irão substituir seu link simbólico.

• Alguns aplicativos procuram o local em que são chamados para recuperar arquivos de configuração, plug-ins e recursos semelhantes. Se você chamar o aplicativo por um link simbólico, seu código poderá falhar em segui-lo e, em seguida, procurar esses arquivos de recurso em torno de /usr/bin onde eles não estiverem.

• Pode haver outros binários em /usr/local/maven/bin e não adicionar esse diretório ao seu PATH os tornará indisponíveis. Removido, pois você já leva isso em conta com seu comando, vinculando todos os potenciais comandos.

• A página maven2 informa para adicionar este diretório ao seu PATH (precisamente: Adicione a variável de ambiente M2 ao seu caminho, por exemplo, PATH de exportação = $ M2: $ PATH .), usando uma abordagem diferente, você está quebrando essa etapa, de forma não suportada. Obviamente, se a maioria dos usuários de um sistema for em potencial maven usuários, faria mais sentido definir o PATH globalmente em vez de cada .profile .

Nota 1:

Documentação do 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.

Padrão de Hierarquia do Debian / Filesystem

/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

Documentação do 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.

Teste simples mostrando dpkg do Debian não preserva um link existente, mesmo quando a opção --force-overwrite não é usada:

# 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

    

Answer 3

Se você quiser criar um link simbólico, seria melhor criar um link simbólico para /usr/local/bin . No meu servidor, eu costumava instalar o software local em /opt/NAME e ligar simbolicamente os binários a /usr/local/bin .

    

Answer 4

Uma alternativa aos dois métodos sugeridos é criar um script de shell em /usr/local/bin que, quando executado, executa o binário que você especificar no script. Por exemplo, usando maven como exemplo, eu criaria um script de shell em /usr/local/bin chamado maven que tem um script pequeno dentro para executar o binário maven onde ele está localizado e passar qualquer argumento para ele:

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

Isso tem o lado negativo de ter que fazer isso para cada binário que você quer "linkar", mas ele permite que você chame esses binários a partir da linha de comando sem precisar alterar sua variável de ambiente $PATH .