Altere globalmente o caminho para todos os usuários, mesmo no cron

Question

Estamos configurando um cluster SGE com CentOS 6. Meu administrador de sistema está instalando aplicativos que não são instalados via RPM (ou seja, por outros meios como make install) e devem ir em um diretório não padrão, neste caso algo como /share/apps/install/bin/. O caminho para isso é atualmente adicionado à maioria das sessões (login, qlogin, etc.) por meio /share/apps/etc/environment.shdo qual é chamado por /etc/bashrc. environment.shtambém anexa algumas coisas ao PERL5LIB.

O problema que estou enfrentando é que /share/apps/install/binnão é adicionado a algumas instâncias, por exemplo, coisas chamadas de um crontab.

Eu sei que posso definir manual e explicitamente PATH=/bin:/usr/bin:/blah/blah:...em meu crontab pessoal ou em qualquer script ou entrada de crontab, mas o que espero é que haja uma configuração em algum lugar fora /etc/profileou /etc/bashrcque coloque o .../bindiretório não padrão em todos os PATHs para todos os usuários .

Answer 1

Adicione um arquivo com o valor que você deseja PATHter em /etc/profile.d. Esses arquivos são configurados para serem originados por shells como Bash, Csh Zsh ou tcsh.

Exemplo

Precisávamos adicionar o seguinte valor ao nosso PATH.

/usr/local/share/bin

Então criamos um arquivo, /etc/profile.d/ourstuff.sh, com a seguinte linha:

export PATH=/usr/local/share/bin:$PATH

Os arquivos com a extensão .shsão provenientes de shells como Bash e Zsh. Os arquivos com a extensão .cshsão provenientes de Csh e tcsh.

EDITAR #1 - Acompanhamento

OP fez a seguinte pergunta de acompanhamento.

Sim, mas e os cron jobs? Existe uma maneira de chegar ao caminho até lá? cron não parece chamar /etc/profile ou /etc/bashrc.

Ao que respondi:

Corrija, não dá nem vai. Você precisa definir o SHELL=/bin/bashcron para substituir o shell padrão (normalmente /bin/sh). Além disso, você pode definir this para crons do usuário, BASH_ENV="$HOME/.bashrc", e this para crons do sistema, BASH_ENV="/root/.bashrc". Seria uma maneira de contornar isso.

Eu sugiro fortemente que você não faça isso. Deixe que os scripts que precisam de um ambiente específico o configurem por conta própria. Não tente resolver todos os problemas a nível global!

Answer 2

Você pode colocar definições de variáveis ​​de ambiente /etc/environment(assumindo que seu sistema carreguepam_envpara todos os serviços, que deve ser o padrão em todos os sistemas Linux modernos não embarcados).

Observe que você só pode colocar definições de variáveis ​​​​de ambiente estáticas, no formato VARIABLE=VALUEou VARIABLE="VALUE", com uma definição por linha. Você não pode ter comandos shell arbitrários, não pode se referir ao valor de outra variável escrevendo FOO=hello+$BAR(isso coloca um literal $no valor de FOO), etc. Contanto que você se atenha a atribuições simples como PATH=/usr/local/bin:/usr/bin:/bin:/share/apps/install/bin, você ficará bem (observe que você não pode usar o diretório inicial do usuário: o valor deve ser o mesmo para todos os usuários).

Answer 3

O que acabamos fazendo foi uma solução multifacetada para evitar quaisquer problemas de caminho. Dependendo do caso de uso, usamos um ou mais dos seguintes:

• Usou caminhos absolutos para os binários instalados em locais não padrão, em vez de esperar que o binário estivesse no caminho. Isso foi usado para ferramentas que possuem poucas ou nenhumas dependências externas não padrão e/ou funcionam isoladamente.
• Criei e utilizei um script wrapper para uma ferramenta que configurava o ambiente conforme necessário; configurando manualmente PATH=... dentro desse script e/ou executando source $HOME/.bashrcconforme apropriado. Isso foi usado para ferramentas que precisavam de outras ferramentas, mas que, de outra forma, podiam ser executadas em nosso cluster.
• Criei um container (Docker no nosso caso) incluindo os binários e uma configuração mais complexa. Isso foi usado para ferramentas que exigem um ambiente significativamente diferente da nossa configuração de cluster padrão.