Adicionando ao caminho x vinculando a partir de / bin

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

Eu acho que poderia ser mais conveniente apenas vincular os poucos programas nessa pasta a partir da /binpasta (ou outra pasta que todos tenham em seu caminho) assim:

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

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

Ligando

Você geralmente não ligar /usr/local/*com /bin, mas esta é mais uma prática histórica. Em geral, existem algumas razões "técnicas" pelas quais você não pode fazer o que está sugerindo.

Criar links para executáveis ​​em /binpode causar problemas:

1. Provavelmente, a maior advertência seria se o sistema estiver gerenciando pacotes por algum tipo de gerenciador de pacotes, como RPM, dpkg, APT, YUM, pacman, pkg_add, etc. Nesses casos, geralmente você deseja deixar o pacote gerente de fazer o seu trabalho e gerenciar diretórios tais como /sbin, /bin, /lib, e /usr. Uma exceção seria o /usr/locallocal normalmente seguro para você fazer o que achar melhor na caixa, sem precisar se preocupar com o fato de um gerenciador de pacotes interferir nos seus arquivos.

2. Muitas vezes, os executáveis ​​criados para /usr/localesse PATH são codificados em seus executáveis. Também pode haver arquivos de configuração incluídos /usr/localcomo parte da instalação desses aplicativos. Portanto, vincular apenas o executável pode causar problemas com esses aplicativos, encontrando os .cfgarquivos 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 .cfgarquivos também pode ocorrer com executáveis ​​"auxiliares" que o aplicativo principal precisa executar. Eles também precisam estar vinculados /usr/bin, sabendo que isso pode ser problemático e só aparece quando você realmente tenta executar o aplicativo vinculado.

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

/etc/profile.d

Em vez disso, se todos os usuários fornecerem esse gerenciamento, o administrador poderá adicioná-lo facilmente a todos que estiverem $PATHna caixa, adicionando um arquivo correspondente no /etc/profile.ddiretório.

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.

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 um loop nas $PATHferramentas que podem estar fora do /bin. O uso de ferramentas como essas é preferível, pois elas seguem mais o que a maioria dos administradores consideraria "prática padrão" e, assim, facilita a transferência de sistemas de um administrador para outro.

Essa ferramenta faz uma coisa semelhante ao criar links /bin; mas ele gerencia a criação e a destruição desses links, portanto, é mais fácil entender a configuração pretendida de um sistema quando realizada por meio de uma ferramenta versus diretamente, como você sugere.

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

A criação de links /bin, embora plausível, provavelmente seria altamente desencorajada pela maioria dos administradores de sistemas:

1. Seria desaprovado porque é visto como personalizado e pode causar confusão se outro administrador for necessário para pegar a caixa
2. Pode levar à quebra de um sistema em um estado futuro como resultado dessa personalização "frágil".

Respondendo às perguntas:

Isso está correto?

Não , é uma prática ruim.

Existem alguns efeitos colaterais ocultos na minha sugestão?

Sim, existem vários efeitos colaterais. Sua sugestão pode funcionar ou não, dependendo do aplicativo, e pode regredir ou ser interrompida a longo prazo.

Existem razões sensatas para não criar um link tão 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é um local tradicional para software criado pelo administrador local, /opt/<packagename>sendo um local para software desagregado. Se você criar um arquivo ou um link /bin, existe o risco de ser substituído por uma instalação de pacote, no seu caso, um mavenpacote hipotético fornecido pelo sistema operacional, que pode levar a uma regressão se o criado localmente for criado a partir de versões mais recentes. código fonte que a versão do sistema operacional. Por exemplo, tarballs SVR4 pkgadd, debian dpkg, red-hat rpme slackware sobrescreverão cegamente o seu link simbólico.

• Alguns aplicativos procuram o local em que são chamados para recuperar arquivos de configuração, plugins e recursos similares. Se você chamar o aplicativo por um link simbólico, seu código poderá falhar em segui-lo e, em seguida, procure esses arquivos de recursos /usr/binonde eles não estão.

• Pode haver outros binários /usr/local/maven/bine a não inclusão desse diretório no PATH os tornará indisponíveis. Removido como você já leva isso em consideração com seu comando, vinculando todos os comandos em potencial.

• A página maven2 diz para adicionar este diretório ao seu PATH (precisamente: adicione a variável de ambiente M2 ao seu caminho, por exemplo, exporte PATH = $ M2: $ PATH .), Usando uma abordagem diferente, você está quebrando essa etapa e, portanto, não é suportado. maneira. Obviamente, se a maioria dos usuários de um sistema são mavenusuários em potencial , faria mais sentido definir o PATHglobalmente do que em cada um .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 Debian / Sistema de Arquivos

/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 o Debian dpkgnão preserva um link existente, mesmo quando a --force-overwriteopção 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

Se você deseja fazer o link simbólico, seria melhor fazer o link simbólico para /usr/local/bin. No meu servidor, eu costumava instalar o software local /opt/NAMEe vincular os binários a eles /usr/local/bin.

Uma alternativa aos dois métodos sugeridos é criar um script de shell em /usr/local/binque, quando executado, execute o binário que você especificar no script. Por exemplo, usando o maven como exemplo, eu criaria um shell script /usr/local/binchamado mavenque possui um pequeno script interno para executar o binário do maven no local em que está localizado e passar quaisquer argumentos para ele:

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

Isso tem a desvantagem de ter que fazer isso para todos os binários que você deseja "vincular", mas permite que você chame esses binários da linha de comando sem precisar estragar sua $PATHvariável de ambiente.