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?
Respostas:
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:
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.
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/
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.
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.
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
A criação de links /bin, embora plausível, provavelmente seria altamente desencorajada pela maioria dos administradores de sistemas:
/bindiretório. Aqui está um exemplo. Nas distros da Red Hat que utilizam o RPM, se um arquivo já existir no /binRPM, não serão instaladas como você descreveu, a menos que sejam coxas para fazer isso usando o --replacefilesswitch. Portanto, essa não é realmente uma razão técnica. O mesmo com outros diretórios. Entendo o que você está dizendo sobre o sistema operacional "proprietário", /binmas não é tão claro quanto você afirma.
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 Removido como você já leva isso em consideração com seu comando, vinculando todos os comandos em potencial./usr/local/maven/bine a não inclusão desse diretório no PATH os tornará indisponíveis.
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:
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
/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
/binou /usr/bin. Ao descobrir os problemas dos binários do sistema ocultos ou desarrumados (o mais famoso foi test), a melhor prática para instalar binários que não são do sistema em outro lugar foi adotada progressivamente.
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.
/opt.